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FOREWORD 

This  manual  is  written  to  serve  as  a  guide  to  Ship  Design  Managers  (SDMs),  Systems  Integration  Managers 
(SIMs),  and  other  design  management  personnel.  It  is  intended  to  aid  in  indoctrination  of  newly  assigned 
personnel  and  serve  as  a  source  for  planning  and  execution  of  each  design  phase.  Since  each  new  ship  design 
project  experiences  unique  situations  and  continued  improvement  in  the  ship  design  process  is  sought,  deviations 
from  procedures  described  in  this  manual  are  expected.  As  the  manual  is  used,  users  are  encouraged  to 
recommend  changes  or  additions  to  SEA  05DT,  SEA  05H,  or  SEA  05V  in  order  that  the  next  issue  will  benefit 
from  user  experience. 

This  manual  covers  content  on  Department  of  Defense  and  Navy  acquisition  regulations  and  Navy  ship  design 
policies  and  practice.  Applicability  of  this  manual  is  to  all  surface  ship  SDMs  -  now  adding  content  for  the  SIM 
and  for  integration  of  mission  modules.  Reference  citations  have  been  verified  and,  where  necessary,  updated. 
For  readability,  selected  content  has  been  hyperlinked  and  moved  into  the  Appendices.  Note  that  the  hyperlinks 
to  the  references  will  only  work  on  the  CD  version  of  the  manual.  See  Appendix  XX  for  a  list  of  acronyms. 

This  manual  is  planned  for  update  every  two  years. 

This  manual  does  not  apply  to  technical  standards  or  procedures  prepared  under  the  cognizance  of  the  Deputy 
Commander  for  Nuclear  Propulsion  or  the  Strategic  Systems  Program  Office. 
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CHAPTER  1 
INTRODUCTION 


1.1  PURPOSE  AND  SCOPE. 

This  manual  is  a  guide  for  Ship  Design  Managers  (SDMs),  Systems  Integration  Managers  (SIMs),  and  other 
design  and  in-service  management  personnel.  It  is  intended  to  aid  in  indoctrination  of  newly  assigned  personnel 
and  to  serve  as  a  source  for  planning  and  execution  of  each  design  phase  for  the  management  of  designs  for  ships 
being  acquired  by  the  Naval  Sea  Systems  Command  (NAVSEA)  and  its  affiliated  Program  Executive  Offices 
(PEOs). 

The  SDM  is  directly  responsible  for  the  successful  management  of  the  ship  design  project  and  for  the  final  design 
package.  For  Warfare  or  Mission  Systems,  procured  by  a  different  Program  Office,  the  SIM  performs  a  similar 
function  to  integrate  the  systems  together  to  a  cohesive  warfare  or  mission  system  and  to  work  with  the  SDM  to 
integrate  the  system  into  the  ship.  The  SDM  and  SIM  must  ensure  the  development  of  a  fully  integrated, 
technically  satisfactory  ship  and  associated  system  designs  that  meet  the  specified  performance  requirements  and 
cost  goals.  All  SDMs  and  SIMs  including  in-service,  are  concerned  with  addressing  technical  issues  associated 
with  design  deficiencies,  modernization,  alterations,  safe  operations  of  ships  and  ship  systems  when  using 
equipment  and  systems  in  a  non-traditional  manner. 

1.2  GUIDELINES  FOR  USE. 

This  manual  sets  forth  ways  and  means  of  performing  the  planning,  coordination,  and  review  functions  required 
of  SDMs  and  SIMs  presuming  sufficient  technical  knowledge  and  experience  to  perform  the  required  tasks.  The 
manual  contains  generic  samples  of  management  products  developed  for  or  by  the  SDM  and  SIM.  General  SDM 
and  SIM  guidance  applicable  to  all  design  phases  is  covered  in  the  main  body  of  the  manual.  More  specific 
guidance  is  provided  in  the  appendices. 

Ship  design  and  acquisition  is  a  complex,  lengthy  process.  Each  one  will  have  differing  requirements;  therefore, 
the  design  processes  themselves  will  differ.  No  single  design  will  follow  exactly  all  the  steps  in  this  manual. 
However,  the  documentation  of  proven  practices  and  lessons  learned  will  facilitate  planning.  Each  new  project 
experiences  unique  situations  and  the  management  process  must  be  tailored.  Therefore,  this  manual  is  not  meant 
to  be  restrictive.  Introduction  of  new  ideas  and  innovations  is  expected. 

This  manual  is  not  a  technical  reference  and  does  not  supplant  other  sources  of  technical  information.  It  is 
hyperlinked  to  a  number  of  reference  documents  and  selected  web  sites  to  ease  access  to  additional  information. 

It  also  contains  numerous  practical  and  hyperlinked  appendices  for  direct  use  by  SDMs  and  SIMs  as  appropriate. 


1-1 


S9800-AC-M  AN-010 


1.3  ORGANIZATION  OF  THIS  MANUAL. 


The  size  of  the  main  body  of  this  document  has  been  substantially  reduced  from  the  prior  revision  to  make  the 
manual  more  usable.  This  has  been  accomplished  by  eliminating  redundancy  and  moving  selected  content  into 
the  appendices.  The  scope  of  responsibility  for  an  SDM  and  SIM  is  broad  and  complex  and  this  document  must 
be  similar.  The  content  of  the  sections  is  as  follows: 

Section  1:  Introduction 

Section  2:  An  overview  of  the  ship  design  and  acquisition  process 

Section  3:  Description  of  the  players  in  the  design  process,  how  they  are  organized,  and  their  roles  and  authorities 
Section  4:  How  to  plan  the  design  effort  and  how  to  structure  the  control  mechanisms  for  its  execution 
Section  5:  The  many  aspects  of  design  execution  and  control 
Section  6:  A  summary  checklist  of  action  items  required 

1.4  EXAMPLE  DOCUMENTS. 


This  manual  specifies  the  contents  and,  to  a  certain  extent,  the  format  of  a  number  of  documents.  For  specific 
“good  examples”  of  a  given  document,  SDMs  and  SIMs  are  encouraged  to  work  with  their  Division  Director  to 
identify  a  prior  work  that  most  closely  resembles  the  current  tasking  expectations.  Most  documents  are  required 
to  be  serialized  and  placed  in  the  online  correspondence  log;  hence  the  correspondence  log  is  a  good  reference 
tool  for  identifying  examples  of  previous  work. 
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CHAPTER  2 

SHIP/SYSTEM  DESIGN  AND  THE  ACQUISITION  PROCESS 

2.1  ACQUISITION  POLICY  AND  DIRECTIVES. 

Overall  policies  for  the  acquisition  of  major  systems,  such  as  a  ship,  by  the  government  are  established  by  Office 
of  Management  and  Budget  (OMB  )  Circular  A-109  of  5  April  1976  (hyperlink).  Department  of  Defense  (DoD) 
Directive  5000.01  (hyperlink),  and  DoD  Instruction  5000.02  (hyperlink).  Secretary  of  the  Navy  (SECNAV) 
Instruction  5000.2  ( hyperlink )  provides  additional  implementation  direction  for  the  Navy.  The  Defense 
Acquisition  Guidebook  (hyperlink)  and  Department  of  the  Navy  (DoN)  Acquisition  and  Capabilities  Guidebook 
( hyperlink )  provide  supplemental  information.  Chairman  of  the  Joint  Chiefs  of  Staff  Instruction  3170.01 
(hyperlink)  and  the  associated  manual  ( hyperlink )  describe  the  capabilities  definition  through  the  Joint 
Capabilities  Integration  and  Development  System  (JCIDS).  Chairman  of  the  Joint  Chiefs  of  Staff  Instruction 
(CJCSI)  6212.01  (hyperlink)  addresses  interoperability  requirements.  Key  NAVSEA  directives  include 
NAVSEAINST  5000.9  on  systems  engineering  ( hyperlink ),  NAVSEAINST  5400.97  on  technical  authority 
(hyperlink),  the  NAVSEA  Engineering  and  Technical  Authority  Manual  ( hyperlink ),  NAVSEAINST  5400.57  on 
engineering  agent  selection,  assignment,  and  responsibility  (hyperlink),  NAVSEAINST  5000.8  on  risk 
management  (hyperlink),  NAVSEAINST  5100.12  on  system  safety  ( hyperlink ),  and  NAVSEAINST  4121.3  on 
technical  standards  (hyperlink). 

A  listing  of  significant  directives  that  define  policies  on  ship  design  and  acquisition  is  presented  in  Appendix  A 
(hyperlink).  Other  DoD  directives  can  be  found  at  http://www.dtic.mil/whs/directives.  SECNAV  and  OPNAV 
directives  can  be  found  at  http://doni.daps.dla.mil,  and  NAVSEA  directives  at 

http://www.navsea.navv.mil/Qrganization/NAVSEA%20Instructions.aspx.  The  Under  Secretary  of  Defense 
(Acquisition,  Technology,  &  Logistics)  (USD  (AT&L))  Defense  Acquisition  Portal  can  be  found  at 
https://dap.dau.mil  and  the  Assistant  Secretary  of  the  Navy  for  Research,  Development  &  Acquisition  (ASN 
(RDA))  provides  acquisition  information  at  https://acquisition.navy.mil/rda/home.  Systems  engineering  policies 
and  processes  are  described  by  the  Assistant  Secretary  of  Defense  for  Research  and  Engineering  (ASD  R&E)  at 
http://www.acq.osd.mil/se/  and  the  Naval  Systems  Engineering  Resource  Center  at  https://nserc.navy.mil.  SEA 
05D  and  the  other  SEA  05  Divisions  maintain  websites  at  the  NAVSEA  Corporate  Data  Management  System 
(CDMS)  at  https://cdms.navsea.navy.mil. 

2.2  TYPES  OF  PROGRAMS. 

Acquisition  programs  are  normally  assigned  an  Acquisition  Category  (ACAT)  designation  as  they  near  formal 
Program  Initiation  either  at  Milestone  A  or  B .  ACAT  designation  confirms  the  Milestone  Decision  Authority 
(MDA)  and  program  assessment  and  supporting  documentation  requirements.  Based  on  their  high  projected  costs 
and  importance,  ship  acquisition  programs  are  generally  assigned  ACAT  level  ID  with  USD  (AT&L)  as  the 
MDA.  Less  costly  and  lower  interest  ship  programs  are  sometimes  assigned  ACAT  level  IC  or  II  with  the 
ASN(RDA)  as  the  MDA.  Smaller  ship  acquisitions  and  modifications  may  be  designated  as  ACAT  III  or  ACAT 
IV  with  MDA  delegated  to  Program  Executive  Officers  (PEOs),  Direct  Reporting  Program  Managers  (DRPMs), 
or  Systems  Commands.  Very  small  programs  that  do  not  require  operational  test  and  evaluation  may  be 
designated  as  Abbreviated  Acquisition  Programs  (AAPs).  These  require  substantially  less  assessment  and 
documentation.  Specific  criteria  are  identified  in  DoD  Instruction  5000.02  (hyperlink)  and  SECNAVINST  5000.2 
(hyperlink). 
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A  non-acquisition  program  is  an  effort  that  does  not  directly  result  in  the  gaining  of  a  system  or  equipment  for 
operational  deployment  and  does  not  require  an  Initial  Capabilities  Document  (ICD).  The  requirement  is  included 
in  a  Sponsor’s  Program  Proposal  (SPP)  input  to  the  Program  Objective  Memorandum  (POM)  and  subsequent 
Research,  Development,  Test  and  Evaluation  (RDT&E)  budget  item  justification  documentation.  Non- 
Acquisition  Programs  use  current  documentation  required  by  the  Program  Planning  Budgeting  and  Execution 
System  (PPBES)  for  management  control. 

An  urgent  need  is  an  exceptional  request  from  a  Navy  or  Marine  Corps  component  commander  for  an  additional 
warfighting  capability  critically  needed  by  operating  forces  conducting  combat  or  contingency  operations.  Failure 
to  deliver  the  capability  requested  is  likely  to  result  in  the  inability  of  units  to  accomplish  their  missions  or 
increases  the  probability  of  casualties  and  loss  of  life.  Urgent  Need  Program  streamlines  the  abbreviated 
requirements,  resources,  and  acquisition  processes  to  address  mission-critical  warfighting  capability  gaps  more 
rapidly  than  the  normal  processes  permit.  Subject  to  statutes  and  regulations,  this  process  is  optimized  for  speed, 
and  accepts  risk  with  regard  to  Doctrine,  Organization,  Training,  Materiel,  Leadership,  Personnel,  and  Facilities 
(DOTMLPF),  integration,  sustainment,  and  other  considerations. 

The  Rapid  Deployment  Capability  process  is  a  tailored  approach  for  initiating  and  managing  development  of  a 
capability  for  rapid  deployment  that  may  transition  to  an  ACAT  program.  It  provides  the  ability  to  react 
immediately  to  a  newly  discovered  enemy  threat(s)  or  potential  enemy  threat(s)  or  to  respond  to  significant  and 
urgent  safety  situations  through  special,  accelerated  procedures. 

A  Joint  Program  is  any  acquisition  system,  subsystem,  component,  or  technology  program  with  an  acquisition 
strategy  that  includes  funding  by  more  than  one  DoD  component  (i.e.,  military  service)  during  any  phase  of  a 
system’s  life  cycle.  Standing  up  a  Joint  Program  Office  provides  for  centralized  organization,  requirements 
definition,  and  funding;  greater  visibility;  co-location  of  personnel  resources;  and  military  representatives  from 
each  service  enabling  more  coherent  program  execution.  Joint  Programs  are  always  complex  and,  for  success, 
require  strong  commitment  and  attention  of  the  highest  levels  of  the  services  involved. 

Participation  in  International  Cooperative  Programs  requires  the  establishment  of  an  International  Agreement  in 
accordance  with  SECNAVINST  5710.25B  (hyperlink).  The  Navy  International  Programs  Office  (IPO)  will  be 
consulted. 
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2.3  UNIQUENESS  OF  SHIP  ACQUISITION. 

Ship  design  and  acquisition  presents  unique  challenges: 

•  Very  low  quantities,  high  unit  costs,  and  a  long  development  cycle 

•  First  ship  must  be  fully  operational.  Full  ship  prototyping  is  rare,  but  when  a  prototype  is  acquired,  it 
must  be  a  fully  operational  ship. 

•  Evolving  requirements  definition 

•  Combat  systems/weapons  systems  development  and  technology  changes  -  development  cycle  of  1 8 
months  or  less  must  be  synchronized  with  the  ship  development  cycle 

•  Integration  of  warfighting  capability  with  supporting  functions  such  as  mobility,  training,  and  damage 
control 

•  The  broad  scope  of  Human  Systems  Integration  (HSI)  considerations  including  Habitability,  Human 
Factors  Engineering  (HFE),  Manpower,  Personnel,  Training,  Personnel  Survivability,  Safety  and 
Occupational  Health 

•  Interoperability  considerations  for  command,  control,  communications,  computer,  intelligence, 
surveillance  and  reconnaissance  (C4ISR);  aviation;  hull,  mechanical,  networks  and  electrical;  and  other 
systems 

•  Extremely  high  parts  count  -  on  the  order  of  10  million  on  a  complex  program 

•  Industrial  base  considerations:  availability,  capability,  and  capacity 

DoD  Instruction  5000.02  (hyperlink)  and  SECNAVINST  5000.2  (hyperlink)  provide  flexibility  for  establishment 
and  program  assessment  of  shipbuilding  programs.  Shipbuilding  programs  may  be  initiated  early  at  the  beginning 
of  Technology  Development.  That  allows  for  approval  of  the  Capability  Development  Document  (CDD)  prior  to 
Preliminary  or  Contract  Design  but  can  require  premature  approval  of  several  other  program  planning  documents. 
Detail  Design  and  Construction  (DD&C)  for  both  lead  and  initial  follow  ships  may  be  authorized  at  Milestone  B. 
Milestone  C  and  the  Full  Rate  Production  Decision  Review  (FRP  DR)  may  be  combined  to  authorize  the 
remaining  follow  ships. 

The  uniqueness  of  ship  acquisitions  often  creates  challenges  for  the  SDM  and  SIM  when  supporting  the  Program 
Office  in  communicating  with  higher  authority  in  DoD.  There  is  usually  little  awareness  of  or  empathy  for 
special  ship-related  issues  in  the  areas  of  Live  Fire  Test  and  Evaluation  (LFT&E)  or  Test  and  Evaluation  (T&E). 
For  example,  lead  ships  are  not  subject  to  live  fire  testing  to  demonstrate  their  survivability,  but  there  is  still 
tremendous  pressure  to  perform  live  fire  testing  on  surrogate  (decommissioned)  ships  during  the  early  design 
phases,  an  expensive  undertaking.  Also,  shock  trials  are  supposed  to  be  done  on  the  lead  ship  unless  a  waiver  is 
granted,  which  usually  always  occurred  in  the  past.  Current  expectations  in  DoD  make  it  less  receptive  to  issuing 
waivers,  however. 

The  SDM  must  support  the  Program  Office  in  preparations  for  program  assessment  including  taking  the  lead  on 
selected  planning  documentation  such  as  the  Systems  Engineering  Plan  (SEP)  and  Corrosion  Prevention  and 
Control  Plan.  SECNAVINST  5000.2  establishes  a  review  process  to  improve  governance  and  insight  into  the 
development,  establishment,  and  execution  of  acquisition  programs  within  DoN.  This  review  process  is  to  ensure 
alignment  between  Service-generated  capability  requirements  and  acquisition,  as  well  as  improving  senior 
leadership  decision-making  through  better  understanding  of  risks  and  costs  throughout  a  program’s  entire 
development  cycle.  This  Navy  Two  Pass/Six  Gate  process  adds  to  the  demands  for  special  planning,  reports,  and 
submissions  now  being  required  across  the  board  for  all  DoN  programs  at  each  milestone.  The  Gates  process 
requires  the  SDM  and  SIM  to  support  6  gate  reviews  including  developing  a  System  Design  Specification  (SDS) 
Plan  for  Gate  3  and  an  SDS  for  Gate  4. 
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2.4  SHIP  LIFE  CYCLE. 

This  section  presents  a  cradle -to-grave  view  of  the  design  process  for  acquisition  to  serve  as  a  framework  for  the 
discussion  of  SDM  and  SIM  responsibilities.  The  terminology  used  in  the  following  discussion  may  not  be 
familiar  because:  (a)  DoD  and  SECNAV  guidance  documents,  such  as  DoD  Instruction  5000.02  and 
SECNAVINST  5000.2,  have  been  repeatedly  revised  in  recent  years  and  the  names  of  the  phases  and  even  the 
milestone  designations  changed,  and  (b)  many  of  the  “traditional”  ship  design  phase  names  look  very  similar  to 
the  new  acquisition  or  system  engineering  phase  names,  but  they  do  not  mean  the  same  thing.  Experience  with 
DoD  for  the  approval  of  recent  ship  program  Systems  Engineering  Plans  (SEPs)  shows  they  will  insist  that  the 
System  Functional  Review  (SFR)  follow  Preliminary  Design  (design  of  the  Functional  Baseline),  the  Preliminary 
Design  Review  (PDR)  follow  Contract  Design  (design  of  the  Allocated  Baseline),  and  the  Critical  Design  Review 
(CDR)  occur  in  Detail  Design  (design  of  the  Product  Baseline).  For  this  reason  this  manual  employs  clarifying 
terminology  such  as  “System  Functional  Review  (System  Engineering  Technical  Review  (SETR)  for  the 
Functional  Baseline),”  “Preliminary  Design  Review  (SETR  for  the  Allocated  Baseline),”  and  “Critical  Design 
Review  (SETR  for  the  Product  Baseline).”  SDMs  and  SIMs  are  encouraged  to  use  this  or  other  equivalently 
explicit  terminology  when  developing  planning  documentation  for  and  briefing  DoD  to  avoid  unnecessary 
conflict. 

The  important  thing  to  keep  in  mind  is  the  level  of  detail  and  maturity  that  is  appropriate  for  each  step  in  the 
design  process  as  well  as  the  calendar  time  needed  to  get  to  that  level. 

Note  that  some  Program  Offices  rename,  combine,  and/or  shorten  these  design  phases  in  an  attempt  to  recover 
from  schedule  delays  or  pursue  unrealistic  schedule  objectives.  The  SDM  and  SIM  must  ensure  that  the  design 
process  is  not  compromised. 

Figure  2-1  shows  how  conduct  of  a  typical  ship  design  and  acquisition  program  aligns  to  acquisition  process 
defined  by  DoD  Directive  5000.01  (hyperlink'). 

As  implied  in  Section  2.3,  warfare  and  other  ship  systems  life  cycles  are  better  aligned  to  the  policies  and 
practices  defined  by  acquisition  statues  and  regulations.  They  are  designed,  often  physically  prototyped,  and 
procured  over  a  much  shorter  timeline.  Their  relatively  narrower  mission  requirements  are  more  easily  defined 
and  measured.  The  SDM  needs  to  work  with  the  SIM  for  weapons  systems  and  the  Technical  Warrant  Holders 
(TWHs)  for  other  system  types  to  plan  for  the  integration  of  new  and  modified  systems  into  the  ship  design  and 
Fleet  modernization  process.  See  Section  5. 
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Figure  2-1.  Ship  Design  and  Acquisition  Process  Under  DoD  Instruction  5000 
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Figure  2-2  illustrates  the  Two  Pass/Six  Gate  review  cycle  with  Program  Initiation  at  Milestone  A  and  Milestone  B 
respectively  under  the  SECNAVINST  5000.2  (hyperlink).  Overlaid  on  top  of  the  DoD  design  and  acquisition 
process,  Pass  One  of  the  SECNAVINST  5000.2  Review  Process  aligns  with  and  starts  with  the  Materiel 
Development  Decision  (MDD)  and  continues  through  the  Materiel  Solution  Analysis  and,  for  Program  Initiation 
at  Milestone  B,  through  the  start  of  the  Technology  Development  Phase. 

Pass  One  Gates  1-3  are  chaired  by  OPNAV  N8  with  the  preponderance  of  leadership  coming  from  the  System 
Command  for  their  preparations.  Pass  Two  Gates  4-6  are  chaired  by  ASN  (RDA)  with  the  preponderance  of 
leadership  coming  from  the  PEO  for  their  preparations. 
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Figure  2-2.  DoN  Requirements/Acquisition  Two-Pass/Six  Gate  Process 

Figures  2-3  and  2-4  provide  a  comparison  to  the  SETR  timing  figures  shown  in  the  Naval  SYSCOM  Systems 
Engineering  Policy  Instruction  (NAVSEAINST  5000.9)  (hyperlink)  -  here  showing  two  different  approaches  to 
ship  design  phasing  and  including  the  timing  for  ship  design  and  acquisition  program  Gates  and  SETRs. 
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Short  statements  of  the  purpose  of  each  design  phase  and  their  relationship  to  the  DoD  and  Navy  acquisition 
processes  follow.  See  Appendix  B  through  M  for  extended  descriptions.  See  Appendix  N  ( hyperlink ).  O 
( hyperlink ).  and  P  (hyperlink)  for  tabular  summaries  of  design  phase  purposes,  alternative  approaches,  leads, 
participants,  workload,  durations,  System  Engineering  Technical  Reviews  (SETRs),  Gate  Reviews,  and 
deliverables.  See  Appendix  Q  ( hyperlink )  for  a  tabular  summary  of  typical  ship  program  SETR  and  other  review 
processes  including  their  puipose,  timing,  roles,  entrance  and  exit  criteria,  and  products. 

Concept  design  level  Exploratory  Design  or  Force  Architecture  Studies  are  routinely  conducted  to  expand  the 
base  of  knowledge  for  planning  future  force  composition.  These  are  not  connected  to  any  particular  ship 
programs.  See  Appendix  B  (hyperlink).  See  also  SEA  05D  Memo  9830  Ser  05D/376  of  28  June  10  Surface  Ship 
Concept  Study  Policy  (hyperlink)  and  the  Concept  Design  Handbook  Version  1 .0  of  22  December  2006 
(hyperlink)  for  specific  guidance  on  the  performance  of  concept  design. 

Concept  or  feasibility  design  level  Pre -Analysis  of  Alternatives  (AoA)  Studies  support  conduct  of  functional 
analyses  such  as  Capabilities  Based  Assessments  (CBA)  to  support  the  Initial  Technical  Review  (ITR), 
development  and  approval  of  the  ICD,  Gate  1  (Navy  ICD  approval),  conduct  of  the  Materiel  Development 
Decision  (MDD),  and  planning  for  the  AoA.  See  Appendix  C  (hyperlink).  See  the  NAVSEA  05T  Guide  for 
Conducting  Technical  Studies  of  27  December  2010  (hyperlink)  and  the  Surface  Ship  Concept  Study  Policy 
(hyperlink). 

Feasibility  design  level  AoA  Studies  characterize  the  AoA  materiel  alternatives  during  the  Materiel  Solution 
Analysis  acquisition  phase  and  support  an  Alternative  Systems  Review  (ASR),  Gate  2  (Navy  AoA  approval)  and 
the  subsequent  Milestone  A.  Conduct  of  a  System  Requirements  Review  (SRR),  submission  of  the  CDD  to  Navy 
staffing  and  Gate  3  (Navy  CDD  approval)  prior  to  Milestone  A  is  now  required.  Pre-Preliminary  Design  starts 
prior  to  Milestone  A  and  Preliminary  Design  may  start  prior  to  Milestone  A.  See  Appendix  D  ( hyperlink )  for 
AoA  Studies,  Appendix  E  (hyperlink)  for  Pre -Preliminary  Design,  and  Appendix  F  (hyperlink)  for  Preliminary 
Design. 

For  ships,  the  Technology  Development  acquisition  phase  that  follows  Milestone  A  may  include  Preliminary 
Design  and  will  include  Contract  Design  to  support  Milestone  B  technology  maturity,  technical  risk,  and 
budgeting  assessment.  See  Appendix  F  ( hyperlink )  for  Preliminary  Design  and  Appendix  G  ( hyperlink )  for 
Contract  Design.  Preliminary  Design  establishes  the  Functional  Baseline  -  i.e.,  verifies  that  the  design  meets  the 
requirements  -  and  concludes  with  a  System  Functional  Review  (SFR)  (SETR  for  the  Functional  Baseline). 
Contract  Design  establishes  the  Allocated  Baseline  -  i.e.,  the  Ship  Specification  and  other  technical 
documentation  for  Detail  Design  and  Construction  contracting  -  and  concludes  with  the  Preliminary  Design 
Review  (PDR)  (SETR  for  the  Allocated  Baseline).  Gate  4  SDS  approval  should  be  scheduled  as  soon  as  possible 
after  Navy  CDD  approval  to  provide  a  firm  basis  for  development  of  the  Ship  Specification.  Gate  5  should  also 
be  scheduled  as  soon  as  possible  to  obtain  higher  authority  concurrence  on  the  approach  for  Request  for  Proposal 
(RFP)  finalization.  This  approach  is  especially  relevant  to  the  design  and  acquisition  of  new  ship  programs  where 
early  buy-in  by  higher  authority  is  needed  to  prevent  costly  changes  in  direction  and  associated  delays  later  in  the 
Program. 

See  Appendix  H  (hyperlink)  for  a  discussion  of  Source  Selections  conducted  in  support  of  Pre-Preliminary, 
Preliminary,  Contract,  and/or  Detail  Design  and  Construction. 

Milestone  B  approves  Program  Entry  into  the  Engineering  and  Manufacturing  Development  acquisition  phase  for 
lead  ship  Detail  Design  and  Construction  and  the  initial  follow  ships.  See  Appendix  I  (hyperlink).  The  Critical 
Design  Review  (CDR)  (SETR  for  the  Product  Baseline)  demonstrates  design  maturity  and  the  Production 
Readiness  Review  (PRR)  demonstrates  manufacturing  readiness  to  begin  production  of  the  lead  ship.  Gate  6  is 
held  for  production  readiness. 

See  Appendix  J  (hyperlink)  for  Conversions  and  Major  Modernizations,  Appendix  K  for  Reactivations 
( hyperlink ),  Appendix  L  ( hyperlink )  for  In-Service  Engineering  and  Appendix  M  ( hyperlink )  for  Aircraft  Carrier 
Modernization. 
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2.5  DESIGN  APPROACHES. 

Historically,  naval  architecture  and  ship  design  have  been  taught  using  the  Classic  Design  Spiral  where  an  initial 
concept  is  iterated  until  the  design  has  converged.  The  Classic  Design  Spiral  is  also  applicable  to  the  impact  of  a 
proposed  engineering  change  during  Detail  Design  or  an  individual  ship  alteration  or  even  a  full  overhaul  package 
during  Fleet  Modernization.  This  would  include  weapons  systems  upgrades. 

More  recently  a  host  of  Synthesis  Model  Based  Design  Optimization  techniques  such  as  response  surface 
methodologies,  Design  of  Experiments,  genetic  algorithms,  and  multi-domain  optimization  have  used  many  point 
designs,  typically  generated  by  a  computer  based  synthesis  program,  to  characterize  the  design  space  for  the 
purpose  of  identifying  the  optimal  characterizations  of  a  solution  to  a  given  set  of  requirements.  More  recently, 
Set -Based  Designs  have  been  employed  to  establish  a  point  design  based  on  an  initial  identification  of  the  feasible 
design  space.  None  of  these  methods  is  universally  better  than  the  others;  each  is  a  tool  that  is  appropriate  for 
different  stages  of  the  acquisition  process  and  different  acquisition  strategies. 

2.5.1  Classic  Design  Spiral  -  Point  Based  Design.  The  design  spiral  approach  is  a  Point  Based  Design 
technique.  As  shown  in  Figure  2-5,  design  activities  are  accomplished  in  a  specific  order.  At  the  end  of  each 
cycle  around  the  spiral,  design  convergence  is  tested.  If  not  converged,  then  another  cycle  at  the  same  fidelity  is 
repeated.  If  converged,  then  the  next  stage  of  design  is  entered  where  the  steps  are  repeated  at  higher  levels  of 
fidelity. 


Owner’s 
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Figure  2-6  presents  an  alternate  view  of  the  Classic  Design  Spiral.  See  also  Section  5.1.  Since  each  design 
iteration  for  a  complex  ship  takes  between  8  to  12  weeks,  relatively  few  design  iterations  are  possible  within  the 
40  to  50  weeks  typically  allocated  to  a  given  stage  of  design.  The  design  is  “done”  when  you  run  out  of  time,  not 
necessarily  when  the  design  is  converged  or  optimal.  For  this  reason,  the  design  spiral  is  most  appropriate  for 
refining  an  existing  solution,  rather  than  as  a  method  for  achieving  the  initial,  almost-optimal  converged  starting 
concept. 


2.5.2  Synthesis  Model  Based  Design  Optimization.  Synthesis  Model  Based  Design  Optimization  techniques 
are  used  extensively  in  the  early  stages  of  design  to  gain  insight  on  the  cost  -  performance  trade-offs  between 
requirements  and  the  feasible  material  solutions.  These  methods  include  response  surface  methodologies,  Design 
of  Experiments,  genetic  algorithms,  and  other  multi-objective  optimization  techniques.  These  methods  are 
generally  characterized  by  the  use  of  many  point  designs,  typically  generated  by  a  computer  based  synthesis 
program.  Because  of  the  need  to  generate  large  number  of  ship  concepts,  the  fidelity  of  the  designs  is  generally 
only  at  the  concept  level.  As  the  design  matures  and  the  required  design  fidelity  increases,  the  ability  to  create 
large  number  of  synthesized  ship  designs  becomes  too  difficult  to  employ  this  method.  The  use  of  high 
performance  computing  environments  with  high  fidelity  synthesis  programs  and  physics  based  analysis  may 
extend  the  use  of  these  optimization  methods  into  Pre-Preliminary  Design. 


Design  Space  Study  1  Design  Space  Study  2  Design  Space  Study  3 


Figure  2-7.  Synthesis  Model  Based  Design  Optimization 
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2.5.3  Set-Based  Design.  Set-Based  Design  (SBD)  as  described  by  Bernstein  (1998)  preserves  design 
flexibility  through  three  basic  tenets: 

•  “Understand  the  design  space 

-  Define  feasible  regions 

-  Explore  trade-offs  by  designing  multiple  alternatives 

-  Communicate  sets  of  possibilities 

•  Integrate  by  intersection 

-  Look  for  intersection  of  feasible  sets 

-  Impose  minimum  (maximum)  constraint 

-  Seek  conceptual  robustness 

•  Establish  feasibility  before  commitment 

-  Narrow  sets  gradually  while  increasing  detail 

-  Stay  within  set  once  committed 

-  Control  by  managing  uncertainty  at  process  gates” 

In  a  Set-Based  Design  process,  engineers  of  different  systems  (i.e.,  electrical  systems,  combat  systems,  hull 
design,  etc.)  communicate  ranges  of  solutions  with  associated  derived  requirements  on  other  systems  and  levels  of 
performance.  As  shown  in  Figure  2-8,  regions  of  feasibility  are  determined  by  the  intersections  of  the  different 
ranges  of  solutions  offered  by  the  different  engineering  disciplines.  Initially,  the  ranges  of  discipline  solutions 
may  need  to  grow  to  enable  a  sufficiently  large  region  of  feasibility  at  the  intersection  of  independent  solutions. 
The  range  of  solutions  for  each  engineering  discipline  is  then  reduced  at  the  process  gates  to  eliminate  subsystem 
solutions  that  are  not  likely  to  contribute  to  a  total  system  solution.  Following  the  reduction  in  design  space, 
engineers  produce  additional  levels  of  details  of  the  subsystems  to  refine  the  solution,  improve  cost  estimates,  and 
reduce  risk.  The  design  space  is  only  reduced  at  a  process  gate  if  the  design  has  sufficiently  reduced  the 
variability  of  design  metrics  to  ensure  with  high  probability  that  the  eliminated  portions  of  the  design  space  are 
Pareto  dominated  by  other  regions.  A  solution  is  Pareto  dominated  when  there  are  other  solutions  which  perform 
better  at  lower  cost.  In  this  sense,  Set -Based  Design  is  about  eliminating  solutions  that  are  likely  not  optimum 
rather  than  picking  one  and  modifying  it  to  become  an  optimum. 

A  marine  engineering  example  of  SBD  would  be  the  interaction  of  hull  shape,  propeller  selection,  and  propulsion 
motor  selection.  For  a  range  of  required  displacements  and  deck  area,  the  hull  designer  would  provide  the  range 
of  speed  -  Effective  Horsepower  (EHP)  curves  and  propeller  size  limitations.  For  this  range,  the  propeller 
designer  would  provide  the  marine  engineer  with  achievable  propeller  efficiencies,  associated  shaft  speed  -  shaft 
power  -  ship  speed  curves  along  with  maximum  shaft  speeds  to  preclude  cavitation.  The  propulsion  engineer 
would  look  at  the  range  of  powers  and  shaft  speed  required,  and  identify  a  motor  architecture  that  could  cover  that 
region.  The  cost  engineer  would  identify  the  cost  and  cost  uncertainty  that  would  apply  to  the  different  design 
spaces. 
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SBD  is  a  design  paradigm  that  pursues  design  solutions  by  eliminating  the  infeasible  and  the  inferior  from  the 
design  trade  in  successive  analysis  iterations,  and  in  so  doing,  delays  design  decisions.  This,  in  turn,  first  slows 
and  then  ultimately  reduces  committed  costs.  In  successive  iterations,  the  current  design  preferences  are  used  to 
generate  successively  higher  fidelity  studies  so  that  the  final  integrated  solution  is  also  of  high  fidelity.  The 
analyses  are  concurrent  and  often  nested  and  all  must  be  well  coordinated  if  the  SBD  is  to  proceed  systematically 
toward  a  high  value,  high  fidelity  solution. 

Based  on  the  experience  in  the  SBD  implementation  for  the  SSC  program,  here  are  some  general  findings  relevant 
to  future  SBD  implementations: 

•  There  was  little  time  to  design  an  executable  SBD  process  before  execution  had  to  begin.  The  process 
used  was  developed  using  the  Decision  Oriented  Systems  Engineering  (DOSE)  method  by  using  the  SBD 
principles  to  determine  the  necessary  key  decisions  to  punctuate  the  effort. 

•  The  SBD  effort  began  after  some  design  space  decisions  had  already  been  made.  In  the  ideal 
implementation  the  SBD  effort  would  commence  with  the  design  trade  space  setup  lest  one  run  the  risk  of 
prematurely  constraining  the  initial  design  trade  space  for  the  problem  at  hand. 

•  The  SBD  process  was  used  on  the  Ship-to-Shore  Connector  (SSC).  Although  the  SSC  Team  was  able  to 
execute  and  boil  down  the  data  to  a  recommended  baseline  within  the  allotted  time,  the  SSC  Team  did  not 
have  the  time  to  generate  successive  design  iterations  across  all  elements  with  increasing  fidelity.  This 
feature  is  essential  to  a  robust  implementation  of  SBD  and  particularly  important  for  flexing  the  design  to 
accommodate  requirement  changes  and  the  like. 

•  With  SSC  the  “system”  was  partitioned  such  that  one  layer  of  partitioned  design  spaces  sufficed.  For 
many  design  problems  this  will  not  suffice. 
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•  It  is  important  to  have  members  of  the  Integration  Team  attached  to  each  of  the  System  Engineering 
Manager  (SEM)  groups  to  ensure  consistent  adherence  to  SBD  principles  and  implementation  procedures 
once  these  procedures  have  been  formulated.  These  Integration  Team  members  will  also  be  responsible 
for  ensuring  that  design  space  reduction  decisions  are  fully  documented  for  traceability.  The  SEM  trade 
space  analyses  will  be  concurrent  and  must  be  well  coordinated  to  ensure  a  relatively  uniform  progression 
in  the  fidelity  of  design  solutions.  All  of  this  means  that  the  Integration  Team  should  be  well  manned  to 
remain  well-connected  with  what’s  going  on  in  the  element  analyses. 

•  The  points  discussed  above  warrant  preparation  time  for  the  setup  and  organization  of  the  SBD  effort. 
Taken  together,  they  almost  demand  that  significant  energies  be  dedicated  to  preparations  for  SBD,  and 
applied  to  the  following:  process  design,  designing  Integration  mechanics,  defining  trade  space  reduction 
and  decision  traceability  protocols,  trade  space  setup,  and  Integration  Team  orientation  regarding  all  of 
the  preceding. 

•  For  a  robust  implementation,  it  is  important  that  the  evaluation  framework  for  valuing  design  solutions  be 
sustained  throughout  the  design  effort.  Once  developed  it  remains  the  best  context  for  considering 
subsequent  design  changes.  While  the  attributes  and  measure  used  in  the  framework  may  need  updating 
with  new  and  better  data,  and  the  scores  of  the  various  design  solutions  in  the  attributes  may  need 
updating,  only  the  evaluation  framework  will  make  sure  that  design  decisions  are  considered  in  fullest 
possible  context.  The  information  in  the  evaluation  framework  may  be  less  than  perfect  at  all  times,  but  it 
will  continue  to  provide  transparency  into  design  decision  influences. 

See  also  David  J.  Singer,  PhD.,  Captain  Norbert  Doerry,  PhD.,  and  Michael  E.  Buckley,  What  is  Set-Based 
Design?  ,  Presented  at  ASNE  DAY  2009,  National  Harbor,  MD.,  April  8-9,  2009  -  Also  published  in  ASNE 
Naval  Engineers  Journal,  2009  Vol  121  No  4,  pp.  31-43. 

Note  that  the  amount  of  visibility  given  to  SDB  in  this  current  manual  should  not  be  construed  to  imply  that  the 
other  methods  are  in  any  way  less  worthy  of  consideration.  The  next  section  discusses  the  appropriate  application 
by  design  phase. 

2.5.4  Application  of  Design  Approach  by  Design  Phase.  During  the  Pre-AoA  and  AoA  phases,  low  fidelity 
automated  models  are  typically  used  to  systematically  explore  the  design  space  in  order  to  trade-off  cost  and 
performance.  The  synthesis  model  optimization  techniques  are  appropriate  to  identify  the  region  of  the  design 
space  where  the  optimal  solution  is  likely  to  reside.  This  region  forms  the  basis  of  the  ICD  and  the  selection  of  a 
broadly  defined  alternative  from  the  AoA. 

Pre-Preliminary  Design  is  a  unique  opportunity  to  perform  trade-offs  among  individual  system  performance,  total 
ship  performance/requirements,  the  Concept  of  Operations  (CONOPS),  and  cost.  Because  these  activities  are 
typically  performed  by  many  geographically  dispersed  organizations,  SBD  techniques  are  ideally  suited  for 
communicating  individual  design  solution  opportunities  and  requirements  to  systematically  neck  down  the  design 
space  while  improving  design  fidelity.  By  the  end  of  Pre -Preliminary  Design,  the  requirements  are  fixed  in  a 
CDD  and  the  CONOPS  formalized  in  a  CONOPS  document.  Note  that  OPNAV  is  developing  a  draft  format  for 
the  CONOPS.  The  ship  design  is  developed  to  the  level  of  detail  necessary  to  produce  a  budget  quality  cost 
estimate.  The  SSC  design  is  a  good  recent  example  of  using  SDB. 

At  the  start  of  Preliminary  Design  following  a  Milestone  A  decision  and  CDD  approval,  the  requirements  and 
CONOPS  for  the  ship  are  largely  fixed.  While  some  change  is  still  possible,  large  changes  are  generally  avoided. 
SBD  can  still  be  desirable  to  further  refine  system  designs  and  integrate  them  into  a  total  ship  design.  At  some 
point,  the  design  will  “converge”  and  the  point  design  based  Classic  Design  Spiral  is  typically  used  to  modify  the 
design  in  response  to  detailed  analysis,  obsolescence  management,  and  optimization  efforts. 

Use  of  the  Design  Spiral  will  typically  continue  through  Contract  Design,  Detail  Design  &  Construction,  and  for 
Fleet  Modernization. 
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CHAPTER  3 

SHIP  DESIGN  PARTICIPANTS 


3.1  GENERAL. 

As  described  in  NAVSEAINST  5401.2  (hyperlink).  NAVSEAINST  5400.57  (hyperlink),  and  the  NAVSEA 
Engineering  and  Technical  Authority  Manual  (hyperlink)  and  consistent  with  NAVSEAINST  5400.97 
(hyperlink),  the  NAVSEA  Competency  Aligned  Organization  (CAO)/Integrated  Product  Team  (IPT)  functional 
design  structure  operates  horizontally  and  vertically  across  all  organizational  boundaries  to  improve  response  to 
customer  workload  requirements.  The  operating  construct  maintains  lines  of  command  and  technical  authority.  It 
also  addresses  workload  forecasting  and  process  development. 

Ship  acquisition  and  associated  system  design  is  a  complex,  lengthy  process.  Each  design  will  have  unique 
requirements.  However,  the  participants’  responsibilities  and  associated  systems  design  processes  are  similar  for 
all  ship  designs.  SEA  05  responsibilities  as  the  NAVSEA  agent  for  ship  design  include: 

•  Conceive  and  develop  integrated  naval  ship  and  associated  system  designs 

•  Act  as  ship  and  associated  system  designer  for  the  command,  establish  overall  design  objectives,  and 
evaluate  engineering  products  and  system  designs  recommended  by  the  command’s  engineering 
directorates  and  other  Systems  Commands  (SYSCOMs)  as  to  their  effects  on  the  total  ship  design 

•  Serve  as  the  principal  advisor  to  the  Commander  and  as  the  principal  point -of -contact  with  all  external 
activities  on  ship  design 

•  Serve  as  technical  authority  throughout  the  ship’s  and  associated  systems’  life  cycle 

The  blue  and  red  boxes  in  Figure  3-1  denote  groups  in  the  SEA  05  organization.  The  exceptions  are  two  red 
boxes  which  are  lead  by  the  Warfare  Center  for  Undersea  Technical  Director  and  Surface  Technical  Director. 

The  IWS  blue  box  is  SEA  05H,  the  organization  which  provides  SIMs  and  TWHs  to  PEO  IWS.  SEA  05V 
provides  the  SDMs  to  PEO  Carriers  and  SEA  05D  provides  the  SDMs  to  PEO  Ships.  There  are  Chief  System 
Engineer/Deputy  Warrant  Officers  leading  the  blue  boxes  and  Technical  Domain  Managers  leading  the  red  boxes. 
SEA  05  and  Warfare  Centers  overall  are  responsible  for  providing  SDMs,  SIMs,  and  TWHs  to  NAVSEA 
Program  Offices  (the  orange  boxes). 

The  Systems  Engineering,  Safety  and  Assurance  Division  of  the  SEA  05  Technical  Policy  and  Standards  branch 
develops  and  promulgates  systems  engineering  policy,  guidance  and  procedures  on  systems  engineering  (e.g., 
Systems  Engineering  Plans  and  the  Systems  Design  Specifications),  and  specialty  systems  engineering  disciplines 
such  as  Reliability  and  Maintainability  and  Safety  Engineering. 
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Figure  3-1.  NAVSEA  Competency  Aligned  Organization 
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3.2  DESIGN  TEAM  COMPOSITIONS. 

Design  team  composition  will  depend  on  the  details  of  the  ship  design.  SDMs  should  work  with  their  Division 
Directors  to  identify  other  ship  designs  to  model  their  Design  Teams  after.  Information  on  Design  Team 
composition  of  other  ship  designs  is  available  in  the  Annual  Reports. 

Where  practicable  and  cost-effective,  system  designs  shall  minimize  or  eliminate  system  characteristics  that 
require  excessive  manpower,  cognitive  or  physical  skills;  entail  extensive  training  or  workload-  intensive  tasks 
which  result  in  mission-critical  errors;  or  produce  safety  or  health  hazards. 

Consistent  with  paragraph  El.  1.29  of  DoD  Directive  5000.01,  the  Program  Manager  shall  apply  HSI  to  optimize 
total  system  performance,  operational  effectiveness,  suitability,  survivability,  safety,  and  affordability.  Program 
Managers  are  required  to  consider  supportability,  life  cycle  costs,  performance,  and  schedule  comparable  in 
making  program  decisions.  Each  program  is  required  to  have  a  comprehensive  plan  for  HSI.  It  is  important  that 
this  plan  be  included  in  the  SEP  or  as  a  standalone  HSI  Plan  as  the  program(s)  may  require. 

In  accordance  with  DoD  Instruction  5000.02,  the  Program  Manager  is  also  required  to  take  steps  (e.g., 
contract  deliverables  and  Government/contractor  LPT  teams)  to  ensure  that  HSI  analysis  and  processes  are 
employed  during  systems  engineering  processes  over  the  life  of  the  program. 

As  a  SDM  or  SIM,  it  is  your  responsibility  to  help  the  Program  Manager  address  these  mandated 
requirements,  and  ensure  that  HSI  requirements  are  addressed  during  the  systems  engineering  process,  included  in 
a  HSI  Plan  and  the  SEP,  and  properly  considered  during  cost/performance  trade-off  analyses. 

Since,  the  key  to  a  successful  HSI  strategy  is  comprehensive  integration  across  the  HSI  domains  and  other  core 
acquisition  and  engineering  processes,  HSI  domain  technical  authorities  should  be  integral  to  the  Design  Team 
composition. 

The  Principle  for  Safety  can  help  the  SDM  or  SIM  scope  the  required  support  and  help  identify  appropriate 
Technical  Warrant  Holders,  Engineers,  or  SMEs  for  the  HSI  domain  areas.  Although  not  always  shown  in  the 
organization  chart,  cost  engineering,  and  reliability  and  maintainability  engineering  support  should  also  be 
established  as  an  integral  part  of  the  design  team. 

3.3  CHIEF  OF  NAVAL  OPERATIONS  SPONSORS.  COMMANDER  FLEET  FORCES  COMMAND. 
JOINT  FORCES  COMMAND,  TYCOMS,  OPERATIONAL  COMMANDS.  FLEET  UNITS,  AND  OTHER 
USER  ORGANIZATIONS. 

An  OPNAV  Sponsor,  via  a  NAVSEA  PEO  or  Program  Office,  usually  initiates  pre-AoA  and  AoA  studies. 
Involvement  of  a  Program  Office  is  not  constant  from  one  project  to  another.  If  one  is  already  in  existence  for  a 
given  ship  type  and  has  been  assigned  responsibility  by  COMNAVSEA,  then  the  OPNAV  Sponsor  for  a  set  of 
new  ship  feasibility  studies  will  usually  communicate  with  it  directly.  A  new  Program  Office  will  not  normally 
be  established  just  for  the  purpose  of  feasibility  studies.  If  one  has  not  previously  been  designated, 
communication  from  OPNAV  of  the  need  will  usually  be  addressed  to  SEA  05.  In  this  case,  SEA  05  will  ensure 
that  the  appropriate  PEO  is  involved  in  any  programmatic  decisions. 

The  OPNAV  Sponsor  is  responsible  for  requirements  definition.  Starting  even  before  the  AoA,  user 
organizations  should  be  brought  into  the  process.  Methods  for  their  involvement  have  included  surveys,  visits, 
workshops,  conferences,  websites,  and  participation  in  design  reviews  and  reading  sessions. 
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SDMs  and  SIMs  are  essential  participants  in  requirements  definition,  ensuring  that  the  performance  and  cost 
trade-offs  are  fully  and  accurately  articulated.  Another  key  aspect  of  this  interaction  is  to  ensure  clarity  and 
understanding  of  requirements  between  the  operational  and  technical  communities.  For  example,  the  SDM  must 
advise  the  requirements  setters  in  OPNAV  and  the  Program  Office,  both  of  whom  may  be  unfamiliar  with  Navy 
standards  and  practices,  on  the  appropriateness  of  proposed  “environmental”  requirements  for  temperature,  sea 
state,  etc.  that  can  drive  the  design.  The  SDM  should  work  with  the  Program  Office  to  ensure  that  the  needed 
studies  are  conducted,  all  relevant  user  organizations  participate,  full  briefings  are  provided  to  stakeholders  and 
higher  authority,  and  results  are  documented  in  technical  reports.  To  this  end,  the  SDM  should  be  one  of  the 
Program  Office  representatives  at  all  requirements  working  groups,  meetings,  and  briefings. 

3.4  JOINT  STAFF  J6,  DEFENSE  INFORMATION  SYSTEMS  AGENCY.  JFCOM.  AND  THE  JOINT 

INTEROPERABILITY  TEST  COMMAND. 

The  Joint  Staff  J6,  Defense  Information  Systems  Agency  (DISA),  Joint  Forces  Command  (JFCOM),  and  the  Joint 
Interoperability  Test  Command  (JITC)  are  reviewing  authorities  for  requirements  documents  and  must  be 
consulted  beginning  with  ICD  development  regarding  interoperability  and  interoperability  testing.  Please  see 
CJCSI  6212.01  (hyperlink)  for  more  information  on  Joint  Staff  J6,  DISA,  JFCOM,  and  JITC  roles  and 
responsibilities  in  the  ship  design  process. 

3.5  PROGRAM  OFFICE. 

Ship/System  design  and  acquisition  responsibility  and  authority  are  normally  assigned  to  a  PEO  Program  Office. 
SDMs  are  assigned  by  SEA  05D/V  to  support  the  Program  Office  for  ships  and  SEA  05H  assigned  SIM  to 
support  PEO  Integrated  Warfare  Systems  (IWS).  SDMs  and  SIMs  shall  participate,  as  appropriate,  in  Program 
IPTs,  Working  Groups,  and  reviews  -  assisting  the  Program  Manager  in  leading  all  technical  aspects. 

Some  Programs  chose  to  establish  a  Technical  Director  within  the  Program  Office  structure  but  now  are  more 
often  choosing  to  establish  a  Principal  Assistant  Program  Manager  for  Integration  who  serves  as  the  technical 
advisor  to  the  Program  Manager  for  issues  related  to  cost,  schedule,  and  technical  risk.  This  new  position  creates 
less  conflict  with  the  role  of  the  SDM.  Each  case  is  somewhat  different,  but  it  is  clear  that  the  SDM  is  the  warrant 
holder  for  ship  design  technical  matters  and  is  held  accountable  to  Commander  NAVSEA.  The  intention  has  been 
that  the  SDM  should  fulfill  the  Program  Manager’s  need  for  a  technical  advisor.  In  some  cases  a  formal 
Memorandum  of  Understanding  (MOU)  may  need  to  be  established  to  clearly  identify  roles  and  functions  to 
avoid  conflict. 

In  the  case  of  systems  under  PEO  IWS,  the  SIM  is  the  TWH.  The  agreement  between  PEO  IWS  and  SEA05  as  to 
how  they  are  to  operate  is  described  in  the  SEA  05/IWS  CONOPS  and  the  Annual  Execution  Agreement  is  the 
financial  agreement  for  a  specific  fiscal  year  on  the  specific  support  for  that  year. 

The  Program  Office  should  be  offered  the  opportunity  at  design  kickoff  meetings  to  highlight  acquisition 
philosophy  for  the  ship  and  associated  systems. 

SDMs  and  SIMs  should  limit  release  of  information  and  contacts  with  higher  authority  and  the  news  media  to 
those  approved  by  the  Program  Office. 

3.6  SHIP  DESIGN  MANAGER. 

An  SDM  will  normally  be  designated  when  either  of  the  following  events  occurs: 

•  The  ship  appears  in  the  Future  Year  Defense  Plan  in  the  current  year  through  three  years  beyond  the 
current  year.  For  example,  in  Fiscal  Year  2012  (FY12),  any  ship  appearing  in  the  Plan  in  FY12,  13,  14, 
or  15  would  call  for  an  SDM. 

•  Upon  receipt  of  a  signed  tasking  from  OPNAV  via  the  Program  Office 
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There  may  be  situations  other  than  the  two  above  which  justify  new  SDM  designations.  They  will  be  considered 
on  a  case-by-case  basis. 

Ship  Concept  Managers  (SCMs)  in  the  Future  Ship  and  Force  Concepts  Division  (SEA  05D1)  perform  the  ship 
design  efforts  prior  to  the  designation  of  a  SDM.  For  a  period  of  time  there  may  be  both  an  SCM  and  SDM  with 
overlapping  responsibilities. 

SDMs  are  designated  in  writing.  Normally,  SDMs  will  not  be  designated  until  competency  has  been  verified 
through  the  completion  of  an  SDM  qualification  card.  See  Appendix  V.  Upon  designation,  the  SDM  will  start 
the  interview  process  for  gaining  their  SDM  Technical  Warrant  as  described  in  the  applicable  NAVSEA 
Instructions.  Until  the  SDM  receives  the  SDM  Technical  Warrant,  the  SDM  will  be  considered  an  “acting” 
warrant  holder. 

SDMs  provide  essential  technical  leadership  in  guiding  the  Navy’s  total  ship  system  engineering  team  supporting 
a  ship  program.  The  SDM  can  expect  a  considerable  amount  of  assistance  from  line  management  with  respect  to 
identifying  internal  manpower  resources.  However,  the  SDM  initiatives  define  the  needs  to  which  management 
must  be  responsive.  The  SDM  is  faced  with  executing  tasks  through  people  he  does  not  directly  supervise  and 
who  will  be  working  part-time  elsewhere.  These  are,  in  many  cases,  respected  authorities  in  their  fields  with  their 
own  professional  objectives,  priorities,  and  programs.  Leadership,  tactfulness,  and  excellent  communication 
skills  are  necessary  attributes  for  any  SDM;  yet  he  must  know  when  to  be  assertive  and  forceful.  The  ability  to 
lead  and  work  through  people  is  probably  the  most  important  qualification  of  the  SDM. 

SDMs  have  the  trust  of  management,  as  reflected  by  granting  SDMs  warranted  technical  authority.  They  are  to 
act  as  objective,  independent,  unbiased  agents  when  evaluating  the  merits  of  individual  technical  issues, 
considering  impacts  at  the  higher  total-system  level.  The  SDM  is  to  bring  all  the  competing  interests  together. 

The  SDM  must  find  solutions  that  support  program  execution  while  meeting  the  technical  requirements  of  the 
engineering  directorate.  A  classic  example  is  a  ship  whose  cost  estimates  necessitate  reductions  in  design  features 
or  even  standards.  The  decisions  an  SDM  makes  are  generally  within  the  bounds  of  accepted  policy  and  practice. 
Where  potential  decisions  are  outside  those  bounds,  SDMs  should  contact  the  affected  warrant  holder  to  discuss 
the  merits  of  the  case  and  obtain  input.  In  rare  cases  where  a  design  standard  has  been  compromised  or  a  warrant 
holder  has  been  overruled  in  the  interests  of  a  total  ship  concern,  the  SDM  must  document  via  serialized 
correspondence  or  other  appropriate  means  the  rationale  for  his  decision.  The  SDM  must  also  inform  the  SEA 
05D/V  management  that  such  a  decision  has  been  made,  and  attempt  to  obtain  the  concurrence  of  the  affected 
warrant  holder.  The  SDM  must  tell  it  like  it  is.  If  an  SDM  is  uncomfortable  with  the  level  of  technical  risk  in  the 
program,  including  the  adequacy  of  risk  reduction  efforts,  then  the  Program  Manager  should  not  be  comfortable 
either.  If  concerns  are  not  being  given  sufficient  visibility,  the  SDM  should  exercise  the  SEA  05  chain-of- 
command  to  resolve  that  situation.  The  SDM  is  ultimately  accountable  for  all  technical  aspects  of  the  product  but 
must  work  within  the  total  program  constraints. 

Sometimes,  the  SDM  must  arbitrate  between  individual  task  leaders  when  conflicts  for  ship  resources  or  design 
preferences  arise.  For  example,  ship  space  and  weight  limitations  may  mean  that  one  task  leader  may  gain  at  the 
expense  of  another.  If  TWHs  cannot  agree  on  a  technical  decision,  the  SDM  should  either  arbitrate  or  raise  the 
issue  to  the  higher  authority  for  resolution.  See  NAVSEA  Memo  Ser  05D/386  of  30  June  2010,  Technical 
Decision  Process  ( hyperlink ).  In  the  case  of  an  American  Bureau  of  Shipping  (ABS)  classed  ship,  an  adjudication 
process  is  defined  in  the  NAVSEA/ ABS  Cooperative  Agreement  Adjudication.  Adjudication  requires  a  mature, 
calm  and  professional  outlook  on  the  part  of  the  SDM  to  maintain  the  proper  perspective  in  regard  to  the  SDM 
role  and  its  obligations. 

The  SDM  will  manage  the  obligations  and  expenditures  of  millions  of  dollars.  These  funds  will  be  committed  to 
industry  and  various  government  agencies  via  numerous  individual  tasks.  This  business  aspect  of  the  job  will  at 
times  be  as  important  as  the  technical  in  regard  to  the  success  of  the  project. 
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The  SDM  is  directly  responsible  for  the  successful  management  of  the  ship  design  project  and  for  the  final  design 
package.  The  SDM  has  the  following  major  responsibilities: 

•  Ensure  the  development  of  a  fully  integrated,  technically  satisfactory  ship  design  that  meets  the 
specified  performance  requirements  and  cost  goals  (The  SDM  must  ensure  that  the  design  is  properly 
documented  and  accomplish  these  tasks  on  schedule  and  within  the  resources  allocated  for  design.) 

•  Serve  as  the  warranted  technical  authority  for  the  ship  assigned.  The  SDM  must  ensure  other  TWHs 
are  engaged  as  necessary  to  resolve  issues.  If  technical  differences  cannot  be  resolved,  the  SDM  must 
document  the  issue  and  arbitrate  or  refer  the  issue  to  higher  authority  for  resolution. 

•  For  the  ship  assigned,  serve  as  the  interface  between  the  technical  community  and  the  Program  Office 
and  OPNAV 

•  Establish  and  communicate  the  design  philosophy  for  the  ship 

•  Establish  and  lead  the  Design  Team  and  interface  with  other  elements  of  the  program  organization 

•  Oversee  development  and  implementation  of  the  Design  Team  Integrated  Digital  Environment  (IDE) 

•  Manage  actions  assigned  to  the  technical  community  and  document  technical  decisions 

•  Where  applicable  for  T-ships  function  as  the  primary  point  of  contact  for  ABS  classification  of  the  ship 

•  Identify  and  manage  risks 

•  Prepare  Plan  of  Action  and  Milestones  (POA&M),  including  cost  and  man-day  estimates,  for  feasibility 
studies,  Pre -Preliminary  Designs,  Preliminary  Designs  and  Contract  Designs  as  requested  by  the 
Program  Office 

•  Negotiate  MOUs  and  memoranda  of  agreement  as  necessary  to  document  relationships  with  external 
organizations 

•  Prepare  financial  obligation  plans  for  the  Program  Office  (The  SDM  must  seek  to  obtain  all  funds 
necessary  for  the  work  and  provide  to  appropriate  codes  as  required.  Manage  ship  design  funds 
allocated  to  the  project.) 

•  Prepare  management  plans 

•  Keep  the  Division  Director  and  SEA  05D/V/05B  informed  of  progress  and  major  events 

•  Maintain,  report,  and  use  metrics  in  the  implementation  of  Continuous  Process  Improvement 

•  Serve  as  mentors  to  the  next  generation  of  SDMs 

•  Remain  technically  current  through  Paining  and  symposium  attendance 

•  Share  lessons  learned  through  annual  reports,  presentations,  and  papers 

•  Provide  the  demand  signal  to  the  SEA  05  TWH  community  for  independent  review,  assessment,  hazard 
and  risk  identification,  and  problem  resolution 

•  Capture,  coordinate,  advocate  for,  and  document  TWH  assessments,  risks,  concerns,  issues  and 
resolutions 

•  Facilitate  practical  trade-offs  and  solutions  to  issues  to  address  TWH  concerns 
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3.7  SYSTEMS  INTEGRATION  MANAGER. 

A  SIM  will  normally  be  designated  when  either  of  the  following  events  occurs: 

•  The  area  of  expertise  and  or  technology  has  been  identified  either  by  a  PEO  or  SEA05 

•  Program  establishment 

There  may  be  situations  other  than  the  two  above  which  justify  new  SIM  designations.  They  will  be  considered 
on  a  case-by-case  basis. 

SIMs  are  designated  in  writing  by  the  Technical  Domain  Manager  (TDM).  Normally,  SIMs  will  not  be 
designated  until  approved  by  the  CHENG  (SEA  05). 

The  SIM  executes  the  Integrated  Warfare  System  Engineering  (IWSE)  Technical  Authority  and  will  be  the 
primary  liaison  to  the  IWS  SEA05H  Chief  System  Engineer.  The  SIM  provides  technical  oversight  to  ensure 
compliance  with  DoD/DoN  standards,  specifications  (non-system  specific),  systems  architecture  guidance, 
performance  metrics,  tools,  and  best  practices.  The  SIM  ensures  compliance  with  PEO  IWS  Enterprise  System 
Engineering  guidance.  See  the  PEO  IWS  Systems  Engineering  Concept  of  Operations  ( hyperlink ).  Specific 
responsibilities  include: 

•  Implements  SEA05/PEO  IWS  CONOPS 

•  Provides  leadership  for  warfare  systems  engineering  process  adherence  and  guidance  for  the  ship 
class/classes 

•  Works  directly  with  the  SDM  to  identify  competency  resource  requirements 

•  Ensures  adherence  to  policy  and  guidance  for  the  planning,  coordination,  and  execution  of  warfare 
system  technical  authority  across  platforms  as  provided  by  the  IWS  SEA  05H  Chief  System  Engineer 

•  Provides  oversight  for  the  review  process  to  align  it  with  emerging  Navy  guidance  regarding  system  of 
systems  design  review  processes 

•  Acts  as  technical  Point  of  Contact  (POC)  for  the  Naval  Warfare  System  Certification 

•  Develops  and  implements  processes  to  ensure  independent  technical  review  of  warfare  system  products 
including  requirements,  architecture,  design,  testing,  and  certification 

•  Provides  the  demand  signal  to  the  SEA05  TWH  community  for  independent  warfare  system  review, 
assessment,  risk  identification,  and  problem  resolution 

•  Provides  senior  level  leadership  to  coordinate  technical  authority  efforts  across  multiple  PEOs  and 
SYSCOMs 

•  Captures,  coordinates,  and  documents  functional  TWH  assessments,  risks,  concerns,  issues  and 
resolutions 

•  Facilitates  practical  solutions  to  issues  to  address  TWH  concerns 

•  Provides  coordination/leadership  to  ensure  proper  interface  of  components,  submittal  of  Government 
Furnished  Information  (GFI),  Required  In  Yard  Date  (RIYD)  supply,  vendor  drawing  approval,  and 
identification  of  risks  and  risk  mitigation  plans  for  system,  system  of  systems,  and  components 

•  In  addition,  may  provide  assistance  in  Technical  Instruction/Technical  Data  Package  development, 
Warfare  Systems  POM  issues,  and  schedule  and  cost  estimates 

•  Ensures  appropriate  TWH  participation  in  Warfare  System  Engineering  Technical  Teams 

•  Ensures  PEO  IWS  Technical  Authority  is  aware  of  any  significant  technical  issues 
Figure  3-2  illustrates  SEA05  H  CAO,  and  how  the  SIM  will  interact  with  the  PEO  IWS  organization. 
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3.8  OTHER  DESIGN  PARTICIPANTS. 

Short  statements  of  the  role  of  other  design  participants  follow.  See  NAVSEANOTE  5400  ( hyperlink )  and 
Appendix  W  for  extended  descriptions. 

•  Deputy  Ship  Design  Manager  is  often  assigned  in  the  case  of  major  or  multiple  concurrent  designs  or  in 
the  planning  and  execution  of  a  major  overhaul.  This  position  has  proven  to  be  justified  for  a  major 
ship  in  Contract  Design  or  in  a  Refueling  Complex  Overhaul,  as  past  experience  shows  that  a  large 
portion  of  the  SDM’s  time  is  devoted  to  communication  outside  the  Design  Team. 

•  Design  Integration  Manager  (DIM),  often  the  existing  Project  Naval  Architect  (PNA),  will  generally  be 
responsible  for  integrating  the  various  elements  of  the  design  and  configuration  control  during  the 
Preliminary  and  Contract  Design  phases. 

•  Ship  Concepts  Manager  (SCM)  leads  the  JCIDS-defined  pre -Milestone  A  tasks  associated  with  the 
development  of  a  CBA,  ICD,  and  sometimes  the  AoA.  He  then  translates  the  insights  and  knowledge 
gleaned  from  that  involvement  to  later  stages  of  the  program,  so  as  to  further  the  SDM’s  ability  to  be 
fully  responsive  to  those  analyses. 

•  Project  Naval  Architect  (PNA)  reports  to  the  DIM  and  provides  assistance  with  vessel  design 
integration  and  configuration  control.  The  primary  focus  areas  for  the  PNA  relate  to  hull  form,  hull 
strength,  hydrodynamics,  sea  keeping  and  survivability,  stability,  structures,  arrangements,  habitability, 
lifesaving  and  mooring  systems,  cargo  handling  systems,  and  deck  systems. 

•  Project  Marine  Engineer  (PME)  reports  to  the  DIM  and  provides  assistance  with  machinery  design 
integration  and  configuration  control.  The  primary  focus  areas  for  the  PME  relate  to  propulsion,  power 
generation,  and  auxiliary  systems. 

•  System  Engineering  Managers  (SEMs)  integrate  and  represent  systems  level  elements  of  the  ship 
design  such  as  hull  systems,  machinery  systems,  combat  systems,  aviation,  C4ISR,  and  others,  as  the 
design  demands.  Each  SEM  is  responsible  to  the  SDM,  associated  SIM  and  TWHs,  and  their 
respective  Group  Directors  for  providing  a  fully  developed  and  properly  integrated  system  that  is 
technically  acceptable  and  meets  the  operational  requirements  of  the  ship  design. 

•  Specification  Manager,  Specification  Task  Manager,  Specification  Editor,  and  Requirements 

Traceability  Manager  manages  development  of  the  Ship  Specifications  and  performs  requirements 
traceability. 

•  Data  Manager  is  responsible  for  preparation  and  processing  of  the  Data  Requirements  List  (DRL)  and 
corresponding  Data  Items  (DIs). 

•  Environmental,  Safety,  and  Occupational  Health  (ESOH)  and/or  Safety  Manager,  and  perhaps  a 
Principal  for  Safety  for  weapons  and  (explosives  safety)  manage  ESOH  for  the  Program. 

•  HSI.  Note  that  the  Technical  Authority  for  HSI  now  flows  from  the  Deputy  Warranting  Officer  to  the 
SDM.  It  is  up  to  the  SDM  to  ensure  there  is  an  HSI  SME  on  the  design  team. 

•  Task  Leaders  are  part  of  the  technical  core  of  the  Design  Team  and  are  responsible  to  the  SEMs  for  the 
execution  of  their  parts  of  the  various  tasks. 

•  Interfacing  Technical  Warrant  Holders  and  Other  Subject  Matter  Experts  -  Selected  TWHs  and  other 
SMEs  will  be  needed  to  review  the  technical  products  and  participate  in  certification  of  the  ship  and  or 
systems. 

•  SEA  05C  Cost  Estimators  are  critical  to  the  performance  of  the  AoA,  subsequent  milestones,  and 
source  selection.  Higher  authority  needs  to  assess  cost  versus  performance  and  establish  suitable 
budgets.  The  SDM  has  the  lead  responsibility  for  providing  design  information  to  SEA  05C. 
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•  SEA  05T  provide  expertise  in  Research  and  Development  (R&D)  program  and  project  management, 
provide  expertise  in  technology  transition,  administer  the  Small  Business  Innovative  Research  (SBIR) 
program,  and  provide  assistance  in  conducting  Technology  Readiness  Assessments. 

•  Government  Furnished  Equipment  and  Information  Managers  (GFE/GFI)  must  be  brought  into  the 
design  process  by  the  SDM  to  verify  the  performance;  space;  weight;  manpower,  personnel  and 
training;  and  services  impacts  of  their  systems.  GFE/GFI  adequacy  and  timeliness  must  be  monitored. 

•  Naval  Reactors  (SEA  08)  is  responsible  for  management  of  all  aspects  of  design,  acquisition  and 
maintenance  pertaining  to  nuclear  propulsion  in  U.S.  Naval  ships  and  submarines. 

•  Naval  Surface  Warfare  Centers  (NSWCs)  are  the  Navy’s  full  spectrum  research,  development,  T&E, 
engineering,  and  Fleet  support  centers  for  ship  hull,  mechanical  and  electrical  systems,  surface  ship 
combat  systems,  coastal  warfare  systems,  and  other  offensive  and  defensive  systems  associated  with 
surface  warfare. 

•  Naval  Undersea  Warfare  Centers  (NUWCs)  are  the  Navy’s  full  spectrum  research,  development,  T&E, 
engineering,  and  Fleet  support  centers  for  ship  hull,  mechanical  and  electrical  systems,  surface  ship 
combat  systems,  coastal  warfare  systems,  and  other  offensive  and  defensive  systems  associated  with 
undersea  warfare. 

•  Ship’s  Force  has  the  overall  responsibility  for  the  maintenance  and  operations  of  all  shipboard  systems 
and  equipment. 

•  Independent  Review  Teams  conduct  design  and  technical  assessments  in  areas  where  technical  risks 
are  high.  Sources  of  independent  reviewers  include  “graybeards,”  academia,  professional 
organizations,  and  industry. 

•  United  States  Coast  Guard  and  American  Bureau  of  Shipping  -  Ships  crewed  by  the  Military  Sealift 
Command  (MSC)  normally  make  maximum  use  of  commercial  standards  and  construction  practices. 
They  are  normally  required  to  be  built  to  ABS  rules,  classed  by  ABS  and  under  USCG  and  Navy 
standards  as  applicable.  See  Appendix  T  (hyperlink). 

•  Shipbuilders,  Integrators,  and  Vendors  -  Consistent  with  the  acquisition  strategy,  industry  should 
participate  in  the  design  process  early  to  gain  an  understanding  of  Navy  requirements,  help  identify 
cost  drivers,  incorporate  producibility  considerations,  and  ensure  the  clarity  and  consistency  of  the 
specifications. 

•  Supervisors  of  Shipbuilding  (SUPSHIP)  offices  and  their  design  divisions  should  be  involved  early  to 
leverage  lessons  learned  for  development  of  the  Ship  Specifications  as  well  as  enforce  NAVSEA 
requirements  during  construction.  See  Appendix  I  ( hyperlink )  and  NAVSEAINST  5400.95  (hyperlink). 

•  Fleet  Modernization  Organizations  are  described  in  Appendix  L  and  Appendix  M. 
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CHAPTER  4 

DESIGN  MANAGEMENT  PLANNING 

4.1  SHIP  DESIGN  PLANNING. 

The  planning  effort  and  a  documented  plan  are  the  keys  to  the  success  of  a  complex  ship  design  project. 

Therefore,  they  should  be  accomplished  as  the  first  effort  in  all  ship  design  projects.  Urgency  to  proceed  with  the 
design  should  not  be  an  excuse  to  bypass  the  planning  step. 

The  extent  of  planning  needed  and  the  size  of  the  formal  plan  will  vary  with  the  nature  of  the  product  and  the 
design  phase.  Planning  should  be  tailored  to  the  need.  A  greater  degree  of  formal  planning  is  needed  for  more 
complex  ships,  more  unusual  procedures,  later  design  phases,  larger  numbers  of  participants,  and  more  unusual 
organizations. 

This  section  describes  major  ship  design  planning  considerations.  Most  of  this  information  will  be  captured  in  an 
Engineering  Management  Plan  (EMP)  authored  by  the  SDM.  Requirements  for  developing  this  plan  are 
described  later  in  this  section.  It  should  be  emphasized  that  a  solid  plan  is  needed  to  support  the  SDM’s  budget 
request.  Furthermore,  financial  and  schedule  planning  are  equally  important  as  technical  planning  in  arriving  at  a 
fully  executable  plan.  Note  that  the  SDM  will  need  to  work  with  the  Program  Office  to  develop  the  separate  SEP 
required  in  support  of  program  assessment. 

4.2  AUXILIARY  &  SPECIAL  MISSION  SHIPS. 

Auxiliary  &  Special  Mission  ships  (commonly  referred  to  a  “T-SHIPS”)  are  generally  procured  for  the  MSC  via  a 
PEO  Ships  Program  Office.  Their  design  and  acquisitions  differ  somewhat  from  those  conducted  for  naval 
warships.  See  Appendix  X  (hyperlink)  for  guidance  based  on  proven  past  practice.  See  ASTM  F1547  and  ASTM 
FI 547-9  for  listings  of  relevant  standards  and  publications  for  commercial  shipbuilding. 

4.3  COMMUNICATIONS. 

Program  Offices  are  normally  the  releasing  authority  for  correspondence  and  other  external  communications 
concerning  their  ships.  SDMs  must  be  compliant  with  both  SEA  05D/H/V  and  Program  Office  protocols  for 
communications  with  other  organizations,  adhering  to  the  most  stringent  requirements  of  each.  Specific 
instructions  have  been  issued  governing  internal  routing,  formal  review,  and  approval  of  acquisition  program 
documents  and  official  correspondence  before  official  program  responses  are  forwarded.  See  SEA  05  Policy  on 
Review  and  Approval  of  Products  for  Distribution  outside  Naval  Systems  Engineering  Directorate,  Ser  05B/066 
of  17  November  2009  (hyperlink). 

SEA  05D/H/V  procedures,  including  appropriate  use  for  different  types  of  correspondence,  sample  templates,  and 
approval  authority,  are  summarized  in  their  shared  folders  on  CDMS.  General  practice  and  formats  are  also 
described  in  the  Navy  Correspondence  Manual  (hyperlink). 

Good  practices  for  briefing  development  are  discussed  in  Appendix  Y  (hyperlink).  See  also  the  standard  SEA  05 
routesheet  (hyperlink)  and  briefing  sheet  (hyperlink). 

The  results  of  design  efforts  shall  be  reported  in  writing  by  NAVSEA  in  the  form  of  a  concise  technical  report 
forwarded  by  serialized  correspondence.  These  are  usually  signed  by  both  a  SEA  05D/V  representative  and  the 
PEO  Ships  Program  Office  for  SDM  reports.  For  SIM  reports  they  are  usually  signed  by  SEA  05H  and  PEO  IWS 
Program  Office.  Please  see  Appendix  Z  (hyperlink)  for  a  report  template.  PowerPoint®  presentations  are  useful 
primarily  as  a  summary  of,  and  not  a  substitute  for,  concise  technical  reports  and  memorandum  for  the  record. 
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SDMs  deal  with  many  matters  that  relate  to  interactions  taking  place  at  the  Flag/SES  level  both  inside  and  outside 
of  SEA.  SEA  05  management  depends  on  SDMs  to  keep  them  apprised  on  such  matters.  It  is  also  important  to 
brief  them  when  there  is  a  need  for  their  involvement,  or  when  it  is  anticipated  that  another  senior  principal  may 
contact  them.  SDMs  must  facilitate  continuous  awareness  on  technical  issues  in  the  SEA  05D/H/V  and  SEA  05 
front  offices.  This  should  also  include  advance  visibility  on  key  program  decision  meetings,  Fleet  or  Type 
Commander  (TYCOM)  actions  and  higher  level  reviews  outside  the  Command. 

4.4  ACQUISITION  STRATEGY. 

The  single  largest  factor  in  planning  any  design  effort  is  selection  of  the  acquisition  strategy.  The  process  of 
arriving  at  the  strategy  is  the  responsibility  of  OPNAV,  SECNAV,  and  the  Program  Office  and  is  beyond  the 
scope  of  this  document.  The  SDM’s  and  SIM’s  role  during  this  phase  is  to  be  an  advisor  to  the  Program  Office  on 
how  process  choices  can  affect  design  evolution.  From  a  design  standpoint,  the  acquisition  options  generally 
align  with  whether  the  government  (i.e.,  Navy)  or  industry  will  perform  the  engineering,  and  for  which  phases. 
The  ship  design  process  can  take  place  in  either  a  cooperative  or  competitive  design  environment.  In  a 
cooperative  one,  a  single  team  is  formed  that  is  composed  of  both  government  and  industry  team  members  usually 
operating  under  a  Navy  lead.  In  a  competitive  design  environment,  two  or  more  industry  teams  each  develop  a 
ship  design  and  compete  for  contracts  to  further  design  and  build  the  ship.  The  type  of  design  environment  used 
for  the  ship  design  affects  the  role  of  government  in  the  design  process,  but  does  not  change  the  basic  design 
process.  In  either  approach  it  remains  the  responsibility  of  the  government  to  ensure  that  a  satisfactory  product  is 
developed  and  delivered  to  the  Navy. 

Figure  4- 1  illustrates  the  range  of  acquisition  strategies  that  have  been  considered  and  employed  for  ship 
procurements.  SDMs  should  work  with  the  Program  Office  to  ensure  their  concerns  are  addressed  in  the  decision 
making  process. 
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Figure  4-1.  Acquisition  Strategy  Alternatives 


Considerations  for  selection  of  the  acquisition  strategy  include: 

•  Maturity  of  requirements  definition  and  technology  development  when  the  design  process  will  be 
turned  over  to  the  shipbuilder(s) 

•  Nature  and  severity  of  risks 

•  Projected  maturity  of  the  design  and  pricing  at  DD&C  award 

•  Potential  for  competition 

•  Availability  of  funding  for  the  conduct  of  multiple  design  efforts 

•  Availability  of  Navy  personnel  for  design,  oversight,  and  source  selection 

•  Availability  of  schedule  for  the  conduct  of  multiple  source  selections 

Transfer  of  design  responsibility  and  risk  to  industry  is  often  cited  as  a  consideration.  Based  on  contracting 
experience  to  date,  the  Navy’s  exposure  does  not  significantly  lessen  when  industry  performs  the  design.  The 
DDG  1000,  LCS,  USCG  Deepwater  Program,  and  unsuccessful  attempt  by  the  CVN  77  to  have  an  integrator 
develop  the  combat  systems  provide  appropriate  lessons. 

Current  policy  discourages  use  of  an  integrator  rather  than  a  Shipbuilder  to  perform  as  the  prime  contractor. 
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Regardless  of  which  acquisition  strategy  is  chosen,  delivery  of  a  ship  that  meets  performance,  cost,  and  schedule 
thresholds  remains  largely  dependent  on  day-to-day  program  execution.  The  devil  is  in  the  details.  The  SDM 
should  participate  in  development  of  all  contracts,  including  the  active  participation  in  the  development  of  how 
each  will  be  administered.  Areas  of  interest  include  use  of  incentives,  SDM  participation  in  the  incentive  process, 
lead/follow  yard  relationships,  integrated  data  environment  and  product  model  requirements,  data  deliverables, 
limitations  on  subcontracting,  directed  subcontracting,  “Buy  America”  requirements,  data  rights,  intellectual 
property,  and  many  others.  See  Appendix  AA  ( hyperlink )  for  a  further  discussion  on  contracting  considerations. 

4.5  DESIGN  TEAM  FORMATION. 

Formation  of  the  Design  Team  is  one  of  the  most  important  functions  of  the  SDM.  It  typically  occurs  early  in  the 
design  process  and,  once  established,  is  lived  with  for  an  extended  period  of  time.  There  are  several  approaches 
to  organizing  and  staffing  a  ship  Design  Team.  The  strategy  for  forming  the  team  is  a  function  of  many  factors, 
such  as: 

•  Acquisition  strategy  determined  by  the  Program  Office 

•  Program  Manager  mindset  on  size  or  makeup  of  the  team 

•  Availability  and  continuity  of  government  personnel 

•  Ability  to  seat  certain  personnel  at  collocated  design  sites  and  their  ability  to  gain  suitable  computer 
access 

•  Funding  availability  for  team  members,  especially  early  on  (e.g.,  lack  of  funding  may  force  use  of 
particular  organizations) 

•  NAVSEA  and,  especially,  SEA  05  policy  and  guidance 

•  Whether  the  ship  will  be  ABS  classed  and/or  IJSCG  certificated 

4.5.1  Use  of  Contractors.  SDMs  should  be  careful  not  to  use  contractors  for  inherently  governmental 
functions  or  personal  services.  Contractor  work  assignments  should  be  completely  and  precisely  specified  in  the 
task  statement  and  formally  issued  to  the  contractor,  rather  than  individual  employees.  The  government  and  the 
implementation  of  those  policies  and  decisions  within  the  system  shall  retain  the  policy  and  decision-making 
function.  It  is  proper  to  use  contractors  to  develop  products  or  draft  technical  inputs,  which  are  used  in  the 
decision  process.  However,  contractors  shall  not  formulate  government  policy  or  define  the  government’s  needs. 
With  the  consent  of  NAVSEA  contracting  (SEA  02),  support  contractors  may  participate  in  development  of  the 
acquisition  strategy  and  may  serve  as  reviewers  on  source  selections. 

Organizational  Conflicts  of  Interest  (OCIs)  may  arise  from  the  contractor’s  relationship  with  both  the  government 
and  a  Shipbuilder.  OCI  is  normally  prohibited  under  NAVSEA  support  contracts.  Waivers  may  be  obtained. 
NAVSEA  Contracting  (SEA  02)  should  be  consulted  for  OCI  determinations. 

4.5.2  Support  Contracting.  NAVSEA  design  support  is  normally  obtained  through  the  NAVSEA  multiple 
award  contract.  Multiple  omnibus  SEA  05  and  other  support  contracts  are  currently  in  place.  Shipbuilder  team  or 
other  industry  participation  normally  requires  the  award  of  new  contracts. 

For  T-ships  support  from  ABS  is  normally  obtained  through  a  direct  contract  that  exists  between  PEO  Ships  and 
ABS. 


4-4 


S9800-AC-MAN-01 0 


4.5.3  Ship  Design  Strategy  for  Contractor  Support.  Ship  Pre -Preliminary,  Preliminary,  and  Contract 
Designs  may  be  categorized  as  a  “Navy  Design”  or  a  “Contractor  Design.”  A  “Navy  Design”  is  one  which 
NAVSEA  retains  firm  “hands-on”  design  control,  making  all  day-to-day  design  decisions,  managing  the  creation 
and  upkeep  of  design  artifacts,  and  performing  design  integration.  Navy  Designs  are  rarely  done  entirely  in-house 
but  employ  varying  degrees  of  design  agent  contractor  support  reporting  directly  to  Navy  personnel.  The  SDM 
Design  Team,  in  concert  with  other  participating  TWHs,  makes  all  major  design  decisions  and  approves  all  other 
design  decisions  as  the  design  develops.  For  T-ships  ABS  review  and  concurrence  is  desirable  if  the  ship  is  being 
ABS  classed.  The  TWHs  are  fully  responsible  for  their  areas  throughout  the  design.  The  distinction  that 
differentiates  a  Navy  Design  from  a  Contractor  Design  is  the  degree  of  design  control  the  Navy  retains. 

A  “Contractor  Design”  is  one  over  which  the  contractor  -  typically  a  Shipbuilder  or  integrator  -  has  “hands  on” 
design  control,  making  all  day-to-day  design  decisions  and  accomplishing  design  integration.  The  role  of  the 
SDM  and  the  government  Design  Team  is  primarily  restricted  to  establishing  design  requirements,  ensuring  the 
requirements  and  design  philosophy  are  understood  by  the  contractor,  tracking  contractor  resource  use,  reviewing 
design  assumptions,  and  conducting  periodic  top  level  reviews  to  ensure  compliance.  NAVSEA  is  still  fully 
responsible  for  the  ship  design  to  perform  the  mission  in  accordance  with  the  Sponsor’s  requirements.  Design 
responsibility  of  some  “fenced”  areas,  such  as  underway  replenishment  and  exterior  communications,  may  be 
assigned  to  organizations  other  than  the  contractor  to  take  advantage  of  specialized  expertise  or  to  ensure 
commonality  with  the  rest  of  the  Fleet.  In  these  cases,  the  SDM  is  responsible  for  managing  the  interfaces  and 
ensuring  the  integration  of  the  efforts  of  multiple  organizations. 

4.5.4  Design  Site  Location.  Co-location  of  the  Design  Team  was  recommended  by  the  1991  NAVSEA  Ship 
Design,  Acquisition  and  Construction  Process  Improvement  Study  and  has  proven  beneficial  for  many  Programs. 
Communications  are  much  easier  and  the  level  of  collaboration  markedly  improves  when  the  design  team  is  co¬ 
located.  Experience  with  recent  Programs  have  again  proven  that,  despite  the  marvels  of  wide  area  network 
computers,  there  is  no  substitute  for  physical  collocation  in  developing  integrated  ship  designs.  SDMs  should 
push  hard  for  this  objective  because  it  will  make  the  design  management  and  control  function  considerably  easier. 
The  Design  Site  is  normally  located  in  or  within  walking  distance  to  NAVSEA  headquarters  to  facilitate  the 
frequent  visits  of  NAVSEA,  PEO,  and  local  support  contractor  personnel  who  may  not  be  co-located.  Computer 
connectivity  and  seating  for  support  contractors  have  proven  to  be  major  stumbling  blocks  for  locating  such  sites 
on  Navy  Yard  premises  and  must  be  carefully  considered. 

4.5.5  Design  Team  Organization  including  IPTs  and  Working  Groups.  Whether  it’s  a  Navy  or  Contractor 
Design,  a  substantial  SDM-led,  in-house  technical  organization  is  required  to  carry  out  the  NAVSEA 
responsibility  of  delivering  quality  ships  to  the  Fleet.  Design  Team  organization  is  typically  functionally  based 
and  must  also  embody  some  form  of  “matrix”  behavior  in  which  so-called  “total  system  engineering”  disciplines 
such  as  HSI,  general  arrangements,  signatures,  logistics,  cost,  safety,  etc.  must  be  involved  with  all  the  hardware 
and  software  disciplines,  such  as  machinery,  deck  systems,  communication  systems,  etc.  For  example,  safety  is 
not  a  design  function  that  can  be  executed  by  itself;  it  must  necessarily  influence  all  the  others.  Similarly, 
designing  the  mooring  system  cannot  be  done  independently  of  the  goals  and  requirements  of  the  total  ship,  such 
as  safety.  In  an  attempt  at  addressing  the  problems  of  matrix  organizations,  Design  organizations  now  incorporate 
ESOH,  HSI,  RAM,  Corrosion  Control,  Risk  Management  and  other  Integrated  Product  Teams  (IPT)  and  Working 
Groups.  Appendix  BB  (hyperlink)  provides  guidance  on  the  implementation  of  IPTs  and  Working  Groups. 

The  SDM,  SIM,  and  other  Design  Team  members  shall  also  participate  in  Program  IPTs  and  Working  Groups  - 
providing  technical  leadership  and  input  as  needed. 
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4.5.6  Evaluating  Design  Team  Capability.  When  assembling  a  Design  Team,  the  SDM  should  evaluate  its 
capabilities  to  determine  organizational  risk  areas  and  to  establish  a  basis  for  implementing  activities  to  improve 
the  Design  Team  efficiency  and  effectiveness.  Appendix  CC  ( hyperlink )  provides  evaluation  guidance. 

4.6  FINANCIAL  PLANNING  AND  EXECUTION. 

Budget  development,  defense,  and  execution  are  among  an  SDM’s  most  important  functions.  Without  budget  the 
SDM  cannot  perform.  Securing  excessive  funding  or  failing  to  obligate  and  expend  in  a  timely  fashion,  however, 
is  a  sure  way  to  lose  credibility.  The  Deputy  Warranting  Officers  (DWOs)  are  responsible  for  securing  funding 
for  the  SIM  and  their  TWHs.  The  funding  can  be  a  combination  of  project  or  Sponsor  funding.  The  demand 
signal  and  funding  will  be  established  yearly  in  the  Annual  Execution  Agreement.  See  Appendix  DD  ( hyperlink ) 
and  Appendix  EE  (hyperlink). 

4.7  SCHEDULE  PLANNING. 

Project  schedules  developed  by  the  SDM  must  be  consistent  with  the  schedules  put  forth  by  the  Program  Office. 
Based  on  the  acquisition  strategy,  the  SDM  should  establish  preliminary  project  schedules  for  the  conduct  of  the 
intervening  design  effort.  Ideally,  SEMs  will  prepare  Work  Task  Assignment/Statement  of  Work  (WT A/SOW) 
schedules  using  the  preliminary  project  schedule  as  guidance.  The  SDM  then  integrates  these,  revises  the 
schedules,  and  negotiates  differences  and  conflicts  with  both  the  Program  Office  and  the  SEMs.  The  importance 
of  a  sound  initial  schedule  cannot  be  overstated.  Change  inevitably  will  occur  and  disrupt  the  most  careful 
planning.  However,  a  well  thought  out  schedule  should  provide  contingency  room  in  risk  areas  wherever 
practical.  A  comprehensive  knowledge  of  milestone  interdependencies  will  be  invaluable  in  restructuring 
planning  when  such  needs  arise  during  the  actual  design  activity.  See  Appendix  FF  for  an  expanded  discussion 
on  schedule  management  (hyperlink). 

The  IWS  DWO  will  develop  an  Integrated  Master  Schedule  (that  will  include  all  major  reviews  including  gate 
reviews).  This  IMS  will  be  used  to  estimate  the  demand  signal  for  a  specific  fiscal  year  as  well  as  a  planning  tool 
for  SIM  and  TWH  to  develop  their  work  schedule  for  a  specific  year.  See  Appendix  GG  for  a  template 
(hyperlink). 

4.8  DESIGN  WORK  PLANNING. 

4.8.1  Work  Breakdown  Structures.  The  Work  Breakdown  Structure  (WBS)  is  the  basic  context  within  which 
the  entire  ship  design  effort  is  planned,  managed,  and  documented.  Care  must  be  taken  to  coordinate 
development  of  the  WBS  with  all  elements  of  the  Design  Team  with  emphasis  on  weights,  cost,  systems 
engineering,  and  production.  MIL-STD-881  (hyperlink)  provides  guidance.  The  Expanded  Ship  Work 
Breakdown  Structure  (ESWBS)  should  be  used  as  a  basis  for  ship  systems.  See  the  ESWBS 
Manual  S9040-AA-IDX-010/SWBS  5D  (hyperlink).  This  provides  a  link  to  historical  data. 
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Figure  4-2.  Ship  Work  Breakdown  Structure  from  MIL-STD-881 

4.8.2  Ship  and  Software  Architectures.  Development  of  the  SEP  requires  a  detailed  description  of  definition 
of  ship  and  software  architectures  and  asks  about  the  employment  of  the  DoD  Architecture  Framework  (DoDAF) 
(hyperlink).  Recent  Programs  such  as  MLP  have  employed  ESWBS  for  the  ship  systems  and  simply  broken  out 
GFE  and  outfit  as  the  other  components  of  the  ship  architecture.  The  software  architecture  has  also  been  defined 
as  a  simple  functional  listing.  DoDAF  use  for  ships  is  normally  limited  to  development  and  documentation  of  the 
C4I  requirements  in  the  CDD.  DoDAF  could  be  employed  on  a  whole  ship  basis  but  that  will  require  a 
considerable  investment  and  may  or  may  not  genuinely  facilitate  requirements  definition  and  ship  design. 
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Figure  4-3.  Sample  Ship  Architecture 
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4.8.3  Design  Structure  Matrix  and  Design  Process  Modeling.  Design  Structure  Matrix  (DSM)  and  Multi 
Domain  Matrix  compactly  represent  the  relationships  between  design  activities.  Figure  4-5  shows  an  example  of 
a  Multi  Domain  Matrix.  In  this  representation,  each  of  the  rows  corresponds  to  a  Design  Activity,  and  each  of  the 
columns  a  Design  Variable.  The  numbered  diagonal  represents  that  Design  activity  for  row  n  produces  as  output 
variable  the  design  variable  in  column  n.  A  dot  in  a  cell  indicates  that  the  associated  design  activity  for  the  row 
takes  as  input  the  design  variable  corresponding  to  the  column  of  the  dot.  By  sequencing  the  design  activities 
within  the  matrix  in  the  order  of  execution,  much  can  be  learned.  Dots  below  the  diagonal  indicate  variables  that 
have  been  produced  by  previous  design  activities.  Dots  above  the  diagonal  indicate  variables  that  are  needed  by  a 
design  activity,  but  are  not  scheduled  to  be  produced  until  the  future.  The  value  of  the  variable  must  be  assumed, 
a  “cluster”  of  activities  must  be  solved  simultaneously,  or  the  design  activities  must  be  re-sequenced. 

Determining  the  optimal  ordering  of  design  activities  is  relatively  easily  accomplished  using  well  known  matrix 
operations. 

Another  insight  that  can  be  easily  observed  is  shown  by  variables  1  and  2  of  Figure  4-5.  These  two  variables  do 
not  depend  on  each  other  in  any  way  and  could  be  solved  in  parallel. 
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Figure  4-5.  Multi  Domain  Example 

See  Appendix  HH  ( hyperlink )  for  a  more  detailed  discussion  of  the  application. 

Efforts  have  also  begun  to  model  the  ship  design  processes  using  PLEXUS  and  other  software  tools.  This  will 
provide  an  initial  template  for  new  ship  design  programs  to  use  to  define,  model,  and  optimize  schedule,  resource 
availability,  and  resource  requirements  for  each  design  phase. 


4.8.4  Sponsor  Tasking  and  Annual  Execution  Agreements.  NAVSEA  ship  acquisition  programs  will 
develop  ship  designs  in  response  to  formal,  signed,  Chief  of  Naval  Operations  (CNO)  tasking  statements 
accompanied  by  funding  and  explicit  statements  of  requirements.  One  formal  Program  Office  vehicle  for 
conveying  program  direction,  funding  authorization,  and  delegation  of  authority  for  ship  acquisition  programs  to 
the  Participating  Acquisition  Resource  Managers  (PARMs),  other  SYSCOMs,  SUPSHIPs,  and  SDMs  has  been 
the  Ship  Project  Directive  (SPD).  The  use  of  the  term  SPD,  at  least  for  SDM  and  SIM  funding,  appears  to  be 
falling  out  of  use. 
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The  Customer  Service  Agreement  (CSA)  or  CONOPS  for  SEA  05H  addresses  the  naval  engineering  demand 
signal  from  the  PEO,  and  how  that  demand  signal  will  be  satisfied  by  the  NAVSEA  Research  &  Systems 
Engineering  (R&SE)  Competency.  The  CSA/CONOPS  is  agreed  to  by  SEA  05  and  the  applicable  PEO. 
Subordinate  to  the  CSA/CONOPS,  individual  Annual  Execution  Agreements  (AEAs)  are  negotiated  between  each 
Program  Manager  and  SDM  assigned  to  each  program.  In  the  case  of  SEA  05H  the  AEA  is  negotiated  between 
PEO  IWS  (all  IWS  PO)  and  IWS  DWO  (SEA  05H).  Once  the  AEA  is  in  effect,  it  shall  be  reviewed  and  updated 
annually.  A  template  for  the  AEA  is  provided  in  Appendix  JJ  (hyperlink)  . 

The  CSA/CONOPS  and  AEAs  are  overarching  in  nature,  and  focus  on  the  research  and  systems  engineering 
needs  of  all  PEO  ship  acquisition  programs  using  a  common  process  and  common  metrics.  The  R&SE 
Competency  will  either  provide  or  manage  all  naval  research  and  engineering  services  in  support  of  the  PEO. 

That  scope  includes  the  following  areas: 

•  Ship  Design,  Total  Ship  Integration,  and  Total  Ship  Systems  Engineering 

•  Cost  Engineering 

•  Human  Systems  Integration 

•  Systems  Safety 

•  Marine  Engineering  (Propulsion,  Auxiliary  Systems,  Hydro,  Stability,  Electrical,  &  Power  Systems) 

•  Ship  Integrity  &  Performance  (Hull,  Structures,  Survivability,  Materials,  &  Environment) 

•  Test  and  Evaluation  Policy/Infrastructure 

•  Warfare  Systems  Ship  Technical  Integration 

•  Cargo/Mission  Systems  Engineering 

•  C4ISR/FORCENet  Ship  Technical  Integration 

•  Aviation  Systems  Ship  Technical  Integration 

•  Network  Systems,  Ship  Technical  Integration 

In  general,  the  execution  of  that  effort  will  be  focused  through  a  warranted  SDM/SIM,  under  the  day-to-day 
guidance  of  the  Program  Manager.  This  scope  will  include  support  from  all  the  research  and  systems  engineering 
provider  communities.  This  agreement  does  not  impinge  upon  relationships  between  PEOs  that  involve  the 
conduct  of  design  and  engineering  on  payload  shipboard  systems  (e.g.,  PARM  relationships  between  PEO  Ships 
and  PEO  IWS  or  PEO  C4I). 

Once  the  plan  and  Design  Team  budget  are  established  for  the  coming  year,  the  SDM/SIM  is  wholly  responsible 
for  execution.  Significant  increases/decreases  in  demand  signal  during  the  execution  year  (e.g.,  program 
expansion/restructuring,  battle  damage,  shift  of  work  from  industry  to  government)  should  trigger  a  renegotiation 
of  resources.  If  a  funding  change  occurs  that  will  impact  the  Design  Team  budget,  Program  Managers  will  enter 
into  discussions  with  the  SDM  and  DWO  for  IWS  to  renegotiate  the  scope  of  required  effort.  If  this  becomes 
necessary,  renegotiation  of  the  AEA  should  be  pursued  to  achieve  an  acceptable  level  of  government  risk. 

4.8.5  Work  Task  Assignments  and  statements  Of  Work.  The  basic  vehicle  for  negotiating  work  agreements 
with  the  design  participants  is  the  WTA  or  SOW.  They  typically  contain  the  following: 

•  Technical  discipline  or  WBS  (WTAs  normally  address  an  entire  technical  discipline.) 

•  Objective 

•  Task  description  and  scope 

•  Deliverables  and  other  outputs,  such  as  support  for  reviews,  etc. 

•  Schedule  and  milestones 

•  Resource  requirements  (usually  expressed  in  $  by  fiscal  year) 
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A  sample  SOW  is  shown  in  Appendix  II  (hyperlink). 

WTAs  or  SOWs  are  developed  for  each  element  of  the  WBS,  using  the  baseline  or  standard  from  a  previous 
similar  design  as  a  point  of  departure.  They  are  managed  by  Task  Leaders  (TLs)  who  report  to  their  respective 
SEMs  on  the  Design  Team.  Deliverable  titles  generally  do  not  change  from  one  design  to  another.  However, 
deliverables  may  be  added  or  deleted  as  required. 

Work  task  assignments  or  SOWs  may  be  initially  drafted  by  the  responsible  SEM/TL  or  as  a  joint  venture  with 
the  SDM.  In  the  former  case,  adequate  guidance  regarding  the  project  (such  as  phase  completion  date,  evaluation 
criteria,  and  budget  planning  guidance)  must  be  provided  by  the  SDM  prior  to  start  of  the  design  phase.  It  should 
be  made  clear  to  the  TLs  that  no  work  is  to  start  until  the  SDM  has  approved  the  WTA  or  SOW. 

4.8.6  Memoranda  of  Understating  and  Memoranda  of  Agreement.  MOUs  and  Memoranda  of  Agreement 
(MOAs)  have  been  used  effectively  to  document  relationships  between  Program  Offices  that  need  to  cooperate. 
MOUs  and  MOAs  have  also  been  employed  by  SDMs  to  formalize  support  arrangements  with  organizations  from 
other  commands.  In  addition  to  identifying  roles  and  responsibilities,  these  documents  usually  define  who  pays 
for  work  that  may  be  undertaken  as  a  result  of  the  agreement  and  how  the  agreement  is  managed. 

4.9  DESIGN  ENVIRONMENT. 

A  smoothly  functioning  design  environment  can  facilitate  the  design  process  and  allow  participants  to  focus  their 
energies  on  design  challenges.  Conversely,  a  poorly  functioning  design  environment  can  drive  up  costs,  disrupt 
schedules,  and  cause  the  design  to  fail.  Design  environment  issues  rarely  have  the  appeal  of  ship  technical  issues 
to  the  SDM.  Nevertheless,  the  design  environment  and  the  collection  of  design  tools  that  will  be  applied  to  the 
program  deserve  the  SDM’s  careful  attention.  See  Appendix  KK  (hyperlink). 

4.10  OTHER  KNOWLEDGE  MANAGEMENT  SYSTEMS. 

While  each  ship  Design  Team  will  likely  maintain  their  individual  Integrated  Data  Environment,  the  SDM  must 
interface  with  a  number  of  other  Knowledge  Management  Systems  maintained  by  SEA  05D  and  other  SEA  05 
codes  on  CDMS,  other  Navy  websites  maintained  by  the  NSWCs  such  as  NSERC,  and  DoD  websites  such  as  the 
Defense  Technical  Information  Center  (DTIC). 

Within  SEA  05,  the  Correspondence  Files  are  the  primary  means  for  capturing  technical  information  for  future 
long  term  re-use.  In  general,  any  technical  decision  by  a  warrant  holder  should  be  documented  in  a  serialized 
memorandum  and  stored  in  the  Correspondence  Files.  The  Annual  Reports  document  a  number  of  lessons 
learned  where  the  lack  of  serialized  documentation  of  warrant  holder  decisions  has  led  to  significant  design  and 
production  rework  at  great  cost.  SDMs  should  also  document  significant  presentations  made  to  senior  Navy 
leadership  as  an  attachment  to  a  memo  to  file  and  insert  the  memo  into  the  Correspondence  File. 

4.11  ENGINEERING  MANAGEMENT  PLANS  AND  PROGRAM  SEP. 

An  EMP  shall  be  prepared  and  approved  prior  to  the  start  of  the  corresponding  design  phase.  The  purpose  of  the 
Engineering  Management  Plan  is  threefold: 

•  Serves  as  principal  vehicle  for  negotiating  the  scope  of  the  effort  desired  by  the  customer,  generally  the 
Program  Office 

•  Demonstrates  that  the  design  can  be  successfully  completed  within  cost  and  schedule 

•  Promulgates  guidance  and  direction  to  project  participants  with  respect  to  project  objectives, 
participants,  responsibilities,  resource  allocation  and  control,  schedule,  technical  and  administrative 
controls,  presentations  and  reviews,  and  final  products 
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Appendix  LL  (hyperlink)  provides  guidance  on  format  and  content  of  the  EMP.  The  EMP  is  approved  by  the 
appropriate  SEA  05D/H/V  Division  Director.  Note  that  this  format  is  intended  to  provide  the  Design  Team 
critical  organizational  and  process  guidance  while  minimizing  duplication  with  the  SEP.  As  the  Lead  Systems 
Engineer  for  the  Program,  the  SDM  is  also  responsible  for  development  of  the  SEP.  Meeting  with  the  DoD  and 
ASN  RDA  Systems  Engineering  organizations  early  in  SEP  development  is  recommended. 

4.12  STUDY  GUIDES. 

For  Navy  Designs,  the  SDM  should  also  develop  and  issue  more  detailed  design  guidance  under  his  signature  to 
the  Design  Team  as  a  design  study  guide.  For  Contractor  Designs,  the  acquisition  strategy  may  dictate 
development  of  specifications  or  a  circular  of  requirements  for  incorporation  in  the  design  contract. 

4.13  PROJECT  DATA  SHEETS. 

Development  and  approval  of  Project  Data  Sheets  (PDSs)  is  required  in  advance  of  selected  documentation  such 
as  the  SEP.  See  the  instructions  ( hyperlink)  and  format. 

4.14  OTHER  MANAGEMENT  PLANNING. 

4. 1 4. 1  Risk  Management.  One  of  the  SDM’s/SIM’s  primary  roles  is  to  support  and  enable  an  effective  risk 
management  process.  This  program  addresses  programmatic  risks  and  system  safety  risks.  Such  a  program  is 
normally  begun  late  in  the  AoA  to  identify  and  mitigate  risks  so  as  to  maximize  the  probability  of  a  successful 
ship  acquisition  program.  DoD  Instruction  5000  requires  a  programmatic  risk  management  process  and  the 
preparation  of  formal  risk  assessments  for  each  Milestone.  Furthermore,  DoD  Instruction  5000  requires  using 
system  safety  risk  management  to  ensure  that  hazards  to  system  users  are  understood  and  accepted. 

NAVSEAINST  5000.8,  Naval  SYSCOM  Risk  Management  Policy,  (hyperlink)  provides  policy  for  managing 
system  acquisition  risks,  both  programmatic  and  system  safety.  The  Defense  Acquisition  University  Publication, 
Risk  Management  Guide  for  DoD  Acquisition,  Sixth  Ed.,  August  2006  (hyperlink)  is  a  practical  reference  to 
programmatic  risk  management.  SDMs  shall  conduct  system  safety  risk  management  in  accordance  with 
MIL-STD-882  ( hyperlink ),  which  provides  the  framework  and  is  referenced  in  DoD  Instruction  5000,  and 
NAVSEAINST  5100.12B,  System  Safety  Engineering  Policy,  Ser  05S/201 1-183  of  3  August  201 1  (hyperlink), 
which  provides  policy  and  direction  tailored  for  NAVSEA  system  safety  risk  management. 

A  primary  goal  of  risk  management  is  risk  acceptance  and  approval.  The  policy  for  this  is  in 
NAVSEAINST  5000.8  (hyperlink)  and  shall  be  followed.  It  is  shown  therein  and  in  Figure  MM-5. 

See  Appendix  MM  ( hyperlink)  for  additional  information  on  risk  management. 

4.14.2  Design  Budgeting.  Allocation  of  design  constraints  such  as  weight,  electrical  power,  bandwidth,  and 
signatures  to  the  subsystem  leads  may  facilitate  the  design  process.  This  process  is  known  as  “design  budgeting.” 

The  design  budget  technique  as  a  management  tool  for  control  of  values  of  key  parameters  such  as  weight  and 
space  and  selected  ship  services  during  the  Preliminary  Design  and  Contract  Design  phases  has  been  implemented 
in  previous  designs  such  as  the  FFG  7,  3K  SES,  DDG  51,  and  most  recently  LCS  and  its  mission  modules.  This 
technique  has  also  been  used  to  permit  continued  combat  system  development  during  Detail  Design  and  was 
successfully  used  in  the  CG  47  and  DDG  51  programs.  The  intended  use  of  the  design  budget  concept  is  to  serve 
as  an  auxiliary  design  control  tool  in  the  Preliminary  Design  and  Contract  Design  phase  and  to  be  available  for 
use  during  early  stages  of  Detail  Design. 
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Design  budgeting  is  a  ship  design  and  acquisition  strategy  that  provides  the  structure  for  contractual 
accommodation  and  management  of  change.  Design  budgeting  allows  continued  development  of  weapon  systems 
and  supporting  ship  systems  following  the  award  of  the  ship  design  and  construction  contract.  Boundaries  on 
time,  compartment  arrangement,  and  ship  services  established  prior  to  contract  award  form  the  limits  of  change 
without  affecting  construction  schedules  or  contract  cost.  Budgeting  is  applied  to  systems  that  are  a  part  of  the 
basic  ship  and  will  be  aboard  the  ship  at  delivery.  It  is  not  applied  to  systems  that  are  planned  for  future 
installation  by  Ship  Alteration  (SHIP ALT). 

Design  budgeting  allows  earlier,  more  independent  and  detailed  system  architectures  earlier  in  design.  When 
design  budgeting  is  used,  design  budget  zones  or  physical  boundaries  are  set  within  the  ship  during  Preliminary 
Design  and  Contract  Design.  The  zone  boundaries  shall  be  established  by  identifying  the  perimeter  of  those 
compartments  that  contain  developmental  systems  or  equipment.  Limits  on  space,  weight.  Heating,  Ventilation 
and  Air  Conditioning  (HVAC),  electrical  power,  and  auxiliary  requirements  shall  be  established  for  each  zone. 
Each  limit  is  set  by  establishing  the  service  requirements  of  each  component  planned  for  installation  in  the  design 
budgeted  zones.  Certain  equipment  in  each  zone  will  not  be  developmental  and  explicit  requirements  can  be  set. 
Requirements  for  developmental  system  components  shall  be  negotiated  with  the  system  developers,  and  design 
budgets,  or  limits,  are  set  for  each  service.  A  margin  on  each  service  is  reserved  for  the  aggregation  of  all  services 
required  in  all  design  budgeted  zones.  This  margin  is  debited  against  Preliminary  Design  and  Contract  Design 
phases,  GFE,  and  Detail  Design  margins.  A  schedule  shall  be  established  for  the  release  of  data  for  each  zone. 

The  schedule  is  to  be  based  upon  estimated  system  development  lead  times  and  Shipbuilder  design  and 
construction  schedules. 

An  example  for  time  budgets  for  warfare  systems  would  be  how  far  the  sensor  needs  to  see/identify  so  the 
operators  have  time  for  appropriate  response.  This  time  will  be  allocated  across  warfare  systems  as  appropriate. 

4.1 4.3  Configuration  Management.  Configuration  management  is  the  process  by  which  changes  to  the  design 
baseline  are  subjected  to  management  attention  and  approval.  During  feasibility  studies  and  Preliminary  Design, 
because  of  the  relatively  small  numbers  of  participants,  an  informal  configuration  management  process  may  be 
followed.  During  Contract  Design,  the  SDM  may  choose  to  delegate  to  the  SEMs  authority  to  approve  changes  to 
the  baseline,  with  only  selected  exceptions  being  referred  to  the  SDM  for  approval.  A  level  of  formal 
documentation  sufficient  to  keep  the  Design  Team  informed  of  changes,  ensure  analysis  is  conducted  on  the 
proper  configuration,  and  to  assure  design  traceability  must  accomplish  this.  The  key  to  configuration 
management  is  effective  communication  accomplished  by: 

•  Easy  access  by  all  participants  to  the  current  and  historical  design  baselines.  Each  iteration  of  the 
design  must  be  clearly  identified  by  its  defining  set  of  design  artifacts. 

•  Frequent  informal  drawing  board  reviews  conducted  by  the  PNA  or  DIM,  SEMs,  and  the  SDM 

•  Timely  advisories  from  SEM  to  SDM/SIM  when  significant  changes  have  been  authorized 

As  the  design  converges,  more  and  more  of  the  ship  system  design  will  be  frozen  and  require  formal  configuration 
control  boards  to  change.  For  example,  because  of  their  effect  on  the  design  of  other  elements  of  the  ship  system, 
the  hull  design  and  propulsion  main  equipment  selections  are  expected  to  be  finalized  relatively  early  in 
Preliminary  Design. 

During  Contract  Design,  the  Specifications,  Contract  Drawings,  and  Project  Peculiar  Documents  (PPDs)  should 
be  progressively  placed  under  formal  configuration  management.  Planning  which  documents  are  to  be  brought 
under  formal  control  and  their  timing  is  an  important  function  of  the  SDM/SIM.  These  dates  should  be  shown  in 
the  EMP  for  each  design  phase. 
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Since  the  Program  Office  maintains  budget  authority,  the  Program  Manager  must  be  involved  in  the  configuration 
management  process.  The  level  of  involvement  of  the  Program  Manager  in  this  process  will  increase  as  the 
design  matures.  As  early  as  Contract  Design,  the  Program  Manager  may  assume  leadership  of  the  configuration 
management  process.  The  DD&C  contract  should  include  language  requiring  the  contractor  to  continue 
configuration  management  through  delivery.  For  contractor  Preliminary  Designs  and  Contract  Designs,  the 
contractor  should  be  required  to  perform  configuration  management  equivalent  to  what  would  be  performed  for  a 
Navy  Design. 

Starting  in  DD&C,  a  formalized  engineering  change  process  is  generally  implemented  to  develop,  price,  and 
approve  changes  in  the  contract.  SDMs  should  ensure  that  they  and  the  appropriate  TWHs  are  reviewing 
authorities. 

See  Appendix  U  ( hyperlink )  for  additional  information  on  configuration  management. 

4.14.4  Design  Review  and  Approval.  Naval  ship  designs  are  normally  subjected  to  a  series  of  informal  and 
formal  reviews  by  NAVSEA  engineering  and  others.  The  scope  of  this  review  should  be  tailored  to  the 
complexity  of  the  design  project,  with  major  combatants  generally  completing  all,  while  auxiliary,  T-ship, 
amphibious  ships,  and  smaller  craft  use  a  subset.  The  process  should  include  documentation  of  requirements, 
standards,  and  products,  together  with  the  corresponding  TWHs  and  stakeholders. 

4. 14.4.1  Design  Decision  Memoranda.  The  SDM  will  develop  a  process  to  record  major  design  decisions 
and  agreements  reached  during  meetings.  These  records  are  generally  referred  to  as  “design  decision 
memorandums”  or  “statements  of  findings”  and  serve  as  supporting  documentation  to  the  SDM,  TWHs,  and 
Program  Manager  to  ensure  all  stakeholders  are  not  only  aware  of  design  decisions  at  the  time  the  decisions  are 
made  but  also  serve  as  a  historical  record  or  “design  history”  if  questions  arise  during  subsequent  design  phases. 

4. 1 4.4.2  In-Process  Design  Reviews.  Informal  and  formal  in-process  reviews  are  scheduled  at  the  peer  and 
higher  levels  typically  at  the  end  of  each  design  iteration.  Subsystems  will  have  special  reviews,  especially  for 
those  undergoing  new  development  with  extensive  prototyping  and  testing. 

4.14.4.3  End-of-Phase,  System  Engineering  Technical,  and  Program  Support  Reviews.  End-of-phase 
formal  reviews  are  generally  conducted  in  concert  with  the  Program  Office,  supporting  SYSCOMs,  and  affiliated 
PARMs  and  support  the  larger  Gate  and  Milestone  program-level  reviews.  Close  coordination  with  the  Program 
Office  is  required. 

The  recent  revision  to  SECNAVINST  5000.2  provides  for  a  common  System  Engineering  Technical  Review 
(SETR)  process.  See  NAVSEAINST  5000.9  (hyperlink).  Each  technical  assessment  culminates  in  a  formal 
meeting  that  documents  recommendations  to  program  management  concerning  the  continuation  of  work  into  the 
next  stage  of  development.  For  ship  Programs  SETRs  are  normally  conducted  in  conjunction  with  a  Technical 
Review  Board  (TRB)  and  Stakeholder  Steering  Board  (SSB)  and  results  in  issuance  of  a  Technical  Feasibility 
Assessment  (TFA).  The  SDM  should  work  with  the  Program  Office  to  consider  whether  or  not  the  TRB  and  SSB 
should  be  held  as  separate  briefings.  See  Section  2.4  and  Appendix  Q  (hyperlink)  for  additional  description  of 
SETR  reviews  and  Appendix  NN  (hyperlink)  for  a  description  of  typical  design  review  content. 

DoD  Systems  Engineering  will  conduct  a  Program  Support  Review  for  ACAT  I  Programs  roughly  six  months 
prior  to  Milestone  A  and  then  for  each  subsequent  milestone.  The  Program  Support  Review  is  basically  an 
inspection  of  Program  readiness  focusing  on  systems  engineering  planning  and  execution  but  touching  on  all 
functional  areas. 
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4.1 4.4.4  ABS  Review.  Where  applicable  for  T-ships,  ABS  is  expected  to  review  the  design  and  approve  those 
aspects  of  it  related  to  classification.  In  addition,  the  Navy  will  review  and  approve  the  entire  design.  See 
Appendix  T  (hyperlink)  for  additional  information  on  ABS  involvement. 

4.1 4.4.5  Fleet  Inputs.  It  is  important  that  each  ship  design  receive  broad  Fleet  inputs.  As  a  minimum,  the 
SDM  shall  arrange,  through  the  appropriate  TYCOM,  a  Design  Team  visit  to  one  or  more  similar  ships  which  the 
new  design  is  intended  to  replace  or  supplement.  Fleet  and  INSURV  reviews  usually  take  place  in  the  later 
design  phases  when  enough  definition  is  available  to  show  specific  operating  system  concepts.  These  can  be 
formal  or  informal  and  may  or  may  not  include  stand-up  of  an  operational  advisory  group  to  improve  continuity 
of  Fleet  membership  over  time.  Fleet  contact  is  usually  managed  through  the  Program  Office  with  the 
involvement  of  the  OPNAV  Sponsor. 

4. 1 4.4.6  Independent  Review.  SDMs  must  be  prepared  for  and  accommodate  independent  review  of  the  ship 
design  by  senior  authorities  from  across  the  Navy  engineering  community,  academia,  industry,  the  Fleet,  and 
other  subject  matter  experts.  Part  of  the  process  that  must  be  fostered  by  SDMs/SIMs  is  regular  interaction 
between  individual  team  members  and  their  senior  managers  in  the  technical  authority  chain. 

4.1 4.4.7  Other  Reviews.  Lastly,  outside  reviews  are  often  required  on  an  individual  program  basis  and  are  not 
covered  here.  For  example,  the  Weapons  Systems  Explosive  Safety  Review  Board  (WSESRB)  will  conduct 
multiple  reviews  of  weapons  safety  during  the  design  development  where  applicable.  See  Appendix  S  (hyperlink) 
for  additional  information  on  typical  certifications. 

4. 1 4.4.8  Program  Office  Involvement.  All  significant  technical  issues  that  cannot  be  resolved  with  the 
Program  Office  will  be  addressed  in  an  issue  paper.  These  one-  or  two-page  papers  must  be  concise  and  easily 
read.  They  will  be  developed  by  or  in  conjunction  with  the  responsible  TWH.  All  shall  be  serialized  and  entered 
into  the  SEA  05D/V/H  information  management  system. 

The  SDM/SIM  must  provide  technical  information  and  backup  material  to  assist  the  Program  Office  in  preparing 
for  review  by  higher  authority. 

4.14.5  Staff  Meetings.  The  SDM  should  hold  staff  meetings  on  a  regular  basis.  These  meetings  provide  a 
forum  for  the  discussion  of  issues  that  affect  the  cost  or  schedule  of  the  design  as  well  as  technical  problems,  risk 
areas,  design  integration,  and  status  of  assigned  action  items.  The  meetings  also  help  to  keep  team  members 
informed  of  overall  design  progress  and  problems,  as  well  as  to  build  team  cooperative  spirit.  Meetings  with  the 
SIM  and  SEMs  could  be  held  weekly  with  less  frequent  meetings  scheduled  for  TLs  as  well  as  SEMs. 

4.1 4.6  Action  Items.  An  effective  action  item  tracking  system  will  be  of  great  benefit  to  an  SDM  by  not  letting 
things  “slip  between  the  cracks.”  Even  simple  methods  like  Excel  spreadsheets  or  MS  Outlook  “to  do”  lists  are 
more  effective  than  trying  to  remember  everything.  The  best  system  is  one  that  is  program-wide  and  used  by  all 
parties.  However,  there  is  often  reluctance  by  the  Program  leadership  to  have  its  actions  visible  to  large  groups 
and,  conversely,  to  have  its  system  inundated  with  lower  level  concerns. 

4.1 4.7  Master  Calendar.  Another  important  activity  is  keeping  a  master  calendar  for  technical  events.  Again, 
the  Program  Office  may  have  one  but  it  may  not  suffice  for  all  the  engineering  needs.  It  should  reflect  key 
meetings,  trips,  tests,  deliverables,  etc.  and  be  updated  daily  if  required.  It  should  be  available  to  the  entire 
Design  Team.  The  SDM/SIM  must  cause  this  to  happen  if  it  does  not  by  other  means. 


4-15 


S9800-AC-M  AN-010 


4. 1 4.8  Security  Classification  and  Document  Marking.  The  SDM  should  work  with  the  Program  Office  and 
SIM  at  the  beginning  of  the  Program  to  identify  the  applicable  security  classification  in  accordance  with  OPNAV 
Instruction  (OPNAVINST)  5513. IF  ( hyperlink )  and  OPNAVINST  5513. 3C  (hyperlink)  and  to  develop  new 
guidance  as  required.  Remember  that  security  is  a  balance  between  risk  and  cost;  every  program  needs  to  tailor 
the  “standard”  guides  to  suit  its  needs.  It  is  critical  for  the  SDM  to  influence  the  classification  guide  for  the 
specific  project  to  allow  the  most  flexibility  in  executing  the  program.  A  good  example  is  that  past  classification 
guides  required  the  general  arrangement  drawings  to  be  Confidential.  Recent  programs  have  fought  hard  to  get 
this  changed  to  Unclassified  For  Official  Use  only  to  avoid  the  entire  CAD/CAM  (computer-aided 
manufacturing)  computer  system  from  having  to  be  classified.  Every  item  to  be  classified  should  be  reviewed, 
with  cognizant  experts  identified  in  the  program  specific  security  classification  guide  and  its  level  reduced  or 
eliminated  to  the  maximum  extent  possible.  Remember  that  Unclassified  does  not  mean  it  is  publicly  releasable. 
All  unclassified  documents  should  have  the  appropriate  distribution  statements  per  DoD  Directive  5230.24 
(hyperlink)  as  well  as  any  required  International  Traffic  in  Arms  Regulations  (ITAR)  warning. 

4.14.9  Program  Protection.  Well  in  advance  of  Milestone  A  as  the  Program  begins,  the  Program  Office,  with 
the  SDM  and  SIM,  must  assess  whether  they  will  be  developing  Critical  Program  Information  (CPI).  This  covers 
the  critical  elements  of  the  system  that  makes  it  unique  and  valuable  to  U.S.  defense  forces.  These  items,  if 
compromised,  would  cause  a  degradation  of  combat  effectiveness,  decrease  the  combat -effective  lifetime,  or 
allow  a  foreign  activity  to  clone,  kill,  or  neutralize  the  U.S.  system.  In  addition  to  the  elements  organic  to  the 
system,  the  Program  Office  shall  consider  any  engineering  process,  fabrication  technique,  diagnostic  equipment, 
simulators,  or  other  support  equipment  associated  with  the  system  for  consideration  as  possible  CPI.  Note  that 
recently  the  definition  of  CPI  and  the  measures  required  for  its  protection  have  greatly  expanded. 

Programs  now  must  develop  a  Program  Protection  Plan  (PPP)  whether  or  not  they  have  CPI.  The  PPP  shall 
include  a  classified  anti-tamper  annex  that  has  ASN  (RD&A)  CHENG’s  technical  concurrence.  Anti-tamper 
refers  to  design  of  new  systems  such  that  they  cannot  be  reverse-engineered  if  they  fall  into  enemy  hands.  While 
whole  warships  are  not  considered  at  such  risk,  parts  such  as  ammunition,  missiles,  or  unmanned  aerial  vehicles 
can  be  captured.  Furthermore,  attention  must  be  paid  to  computer  system  hacking  via  external  communications 
systems.  Draw  a  box  around  the  ship.  Anything  that  crosses  that  box  is  a  candidate  for  anti-tamper. 

An  additional  aspect  of  new  system  development  is  the  potential  for  overseas  sales.  For  example,  the  new  X-band 
radar  on  DDG1000  may  be  sold  in  altered  forms  oversees.  It,  therefore,  needs  to  be  developed  with  an  anti¬ 
tamper  program  plan. 

4.15  REPORTING. 

4. 1 5. 1  Keeping  Management  Informed.  SDMs/SIMs  are  the  eyes  and  ears  of  SEA  05  management. 
Accordingly  they  are  responsible  for  keeping  SEA  05  management  informed  of  progress  and  significant  technical 
issues  on  a  timely  and  regular  basis.  This  should  be  done  weekly  at  the  very  least,  and  daily  as  the  situation 
dictates.  SEA  05  should  not  be  the  first  to  hear  about  issues  from  the  PEO  or  Program  Manager.  SDMs  and 
SIMs  deal  with  many  matters  that  relate  to  interactions  taking  place  at  the  Flag  and  Assistant  or  Deputy  Assistant 
Secretary  of  the  Navy  levels,  both  inside  and  outside  of  SEA.  SEA  05  management  depends  on  SDMs  and  SIMs 
to  keep  it  apprised  on  such  matters.  It  is  also  important  to  brief  SEA  05  when  there  is  a  need  for  involvement  or 
in  anticipation  that  another  senior  principal  may  contact  SEA  05  management.  SDMs  and  SIMs  must  facilitate 
continuous  awareness  on  technical  issues  in  the  SEA  05D/H/V  and  SEA  05  front  offices.  This  should  also 
include  advance  visibility  on  key  program  decision  meetings  and  higher  level  reviews  outside  the  Command.  To 
these  ends,  SDMs  and  SIMs  should  not  limit  themselves  to  the  reports  listed  below.  Status  reports  should  be 
provided  orally  or  through  email,  as  needed,  to  division  directors.  For  significant  technical  issues,  SDMs  and 
SIMs  should  produce  formal  documentation  in  the  form  of  serialized  memos,  white  papers,  and  technical  reports. 
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4.1 5.2  Management  Metrics.  SEA  05,  Program  Offices,  and  Shipbuilders  have  employed  metrics  to  measure 
progress  and  manage  ship  design  and  construction  efforts.  Examples  include: 

•  Independent  collection  and  analysis  of  production  data  by  PMS  377  to  progress  DD&C 

•  Use  of  an  Oracle-based  workflow  system  with  automated  status  by  the  Sealift  SDMs  to  manage  review 
of  the  large  quantity  of  design  deliverables  produced  by  the  Shipbuilders 

•  Tracking  by  PEO  Carriers  of  planned  and  unplanned  action  completions  versus  schedule 

Some  metrics  tracking  efforts  have  worked  and  others  have  not.  It  is  important  that  the  value  of  tracking  the 
metrics  be  generally  recognized  and  that  the  process  not  impose  a  significant  new  workload  for  its  own  sake. 
Ideally,  the  process  should  either  be  fully  automated  or  only  involve  data  collection  by  a  single  analyst.  Two 
things  should  be  considered  in  selecting  a  metric: 

•  Will  it  be  used  to  actually  manage  the  program?  (Who  will  look  at  it  and  what  actions  will  be  based  on 
it?) 

•  Will  this  be  useful  in  providing  feedback  to  the  people  who  will  provide  the  data?  (If  the  workers  do 
not  also  see  and  use  the  results,  they  will  quickly  stop  supporting  submission  of  quality  data.) 

The  metrics  most  commonly  used  are: 

•  Financial  (obligated  and  expended  versus  plan,  earned  value  management  system  [EVMS]) 

•  Deliverables  (on-time,  late,  quality  measures) 

•  Schedule  progress  (tracking  against  milestones  in  WTA  plans) 

•  Staffing  levels  (actual  versus  planned) 

SDMs,  SEA  05D1,  the  National  Shipbuilding  Research  Program,  MANTECH,  and  SBIR  are  required  to  collect 
and  present  their  ship  design  project  metrics. 

4.15.3  Design  Notebooks.  Each  TL  should  be  required  to  maintain  an  electronic  design  notebook  on  the 
design  IDE.  The  notebook  should  reflect  the  design  rationale  used  and  alternatives  considered  but  discarded. 
Tabulated  results  of  calculations  and  sources  and  currency  of  vendor  data  should  be  included.  A  well -prepared 
design  notebook  has  been  found  to  be  a  very  valuable  resource  for  the  functional  code  in  responding  to  queries 
during  DD&C  and  afterwards.  Design  notebooks  may  take  the  form  of  computer  files  vice  paper  and  should  be 
properly  backed  up.  Sharing  of  in-process  files  within  a  design  notebook  is  an  excellent  way  for  team  members  to 
stay  up  with  the  evolving  design.  Design  notebooks  should  be  maintained  even  if  the  design  is  being  done  by  an 
outside  organization.  SDMs  should  regularly  remind  their  staff  members  of  their  importance  and  occasionally 
spot  check  samples  for  quality  and  recognition. 

4.15.4  Annual  Reports,  Audit  Trail,  Design  History,  Red  Book,  and  Lessons  Learned.  Each  project 
should  build  a  record  as  it  progresses  through  the  design  phases.  SDMs  are  responsible  for  maintaining  a  design 
history  and  audit  trail  of  decisions  made  on  their  projects.  This  should  address  design  constraints,  ship  baselines 
and  excursions  studied,  trade  studies  conducted,  and  the  rationale  for  major  design  decisions.  A  track  of 
personnel  and  financial  resource  utilization  should  also  be  included.  Comprehensive  lessons  learned  should  be 
prepared  to  add  to  the  Navy’s  body  of  knowledge  in  ship  design  management.  Such  historical  information  and 
data  (i.e.,  intellectual  capital)  is  also  shared  with  the  Center  for  Innovation  in  Ship  Design  (CISD).  The  Red 
Book,  which  has  been  superseded  by  the  annual  report  for  surface  ship  designs,  provides  summary  information 
from  past  programs.  SEA  05  Memorandum  5400  Ser  05D/174  of  29  March  2010,  NAVSEA  Surface  Ship 
Lessons  Learned  Feedback  Process  Technical  Operating  Procedures,  establishes  a  process  for  identification  and 
recording  of  in-service  lessons  learned. 
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See  SEA  05D  Memorandum  5000  Ser  05D/450  of  21  July  2010  (hyperlink)  for  Annual  Report  requirements.  The 
unclassified  portion  of  the  Annual  Report  (minus  the  separately  provided  Ship  Specifications/Contract 
Drawings/Project  Peculiar  Documents  CD-ROMs)  shall  be  stored  electronically  on  CDMS  in  the  appropriate 
folder.  The  annual  reports  shall  be  provided  in  the  native  format  and  in  an  Adobe  Acrobat  (.pdf)  file  format. 

4. 1 5.5  Design  Reports.  SDMs  shall  develop  a  formal,  written  design  report  at  the  end  of  feasibility  studies, 
Pre-Preliminary  Design,  Preliminary  Design,  and  Contract  Design.  Please  see  Appendix  Z  (hyperlink)  for 
guidance  in  preparing  design  reports. 

4.1 5.6  Use  of  Single  Sheet  Design  Summaries  -  “Placemats”.  SDMs  and  management  have  found  the  use 
of  single  sheet  design  summaries,  “placemats,”  a  valuable  reference  for  their  day-to-day  operations  and  for 
meetings  with  stakeholders.  Surface  ship  SDMs  are  required  to  maintain  their  program  “placemats”  up  to  date  on 
the  SEA  05D  shared  directory. 

4. 1 5.7  Conducting  Briefings.  Guidelines  for  the  conduct  of  briefings  are  provided  in  Appendix  Y  (hyperlink). 

4.15.8  Earned  Value  Management  System.  SECNAVINST  5000.2  (hyperlink)  requires  EVMS 
implementation  for  certain  Programs  in  accordance  with  the  guidelines  in  American  National  Standards 
Institute  (ANSI)/Electronic  Industries  Alliance  (EIA)  -748-1998.  Shipbuilding  Programs  will  typically  be 
required  to  implement  a  plan  (Performance  Measurement  Baseline)  within  their  EVMS.  The  SDM  generally  is 
involved  as  a  member  of  the  program  team  conducting  the  Integrated  Baseline  Review  and  evaluating  monthly 
and  quarterly  EVM  performance  reports. 

4.15.9  Disposition  Of  Design  Data.  See  Appendix  OO  (hyperlink). 
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CHAPTER  5 

DESIGN  PHASE  EXECUTION 


5.1  DESIGN  PROCESS. 

Ship  and  associated  system  design  is  an  inherently  iterative  process.  This  is  because  the  end  result,  the  technical 
definition  of  the  ship  and  associated  systems,  is  based  on  assumptions  that  cannot  be  validated  until  all  aspects  of 
the  design  have  been  developed  to  approximately  the  same  level  of  technical  maturity  or  confidence.  In  the 
context  of  naval  ship  design,  the  iterations  are  accomplished  by  a  series  of  “design  cycles.”  The  purpose  of  this  is 
to  successively  diminish  the  variation  between  the  assumptions  implicit  at  the  start  of  the  iteration  and  the 
technical  definition  at  its  end.  This  process  is  known  as  “convergence”  and  applies  to  all  aspects  of  the  design. 
For  instance,  the  displacement  of  the  ship  may  be  assumed  at  the  start  of  a  design  cycle  to  be  8,000  tons,  based  on 
the  previous  cycle.  After  going  through  a  design  iteration  in  which  structure,  outfitting,  mission  systems,  fuel 
load,  etc.  are  recalculated,  the  new  displacement  is  estimated  to  be  8,100  tons. 

During  each  cycle,  the  team  attempts  to  ensure  that  the  design  (1)  is  self  consistent  (e.g.,  area  available  equals 
area  required);  (2)  satisfies  established  performance  requirements,  such  as  speed  and  endurance,  as  well  as 
established  design  practices,  and  (3)  meets  cost  goals. 

Sometimes  the  ship  design  process  is  illustrated  as  a  spiral  in  which  design  activities  are  performed  sequentially 
and  repeatedly  until  the  design  converges  to  a  self-consistent  technical  definition.  The  spiral  analogy  is  not 
entirely  appropriate  for  naval  ship  design  since  schedule  and  budget  considerations  require  that  many  design 
activities  be  accomplished  in  parallel  rather  than  in  series  as  the  spiral  analogy  implies.  Figure  5-1  is  an 
illustration  of  a  typical  design  cycle  (i.e.,  design  iteration)  in  which  most  tasks  are  conducted  in  parallel.  It 
indicates  the  nominal  scheduling  relationships  and  general  data  flow  that  occur  during  Preliminary  Design  and 
Contract  Design.  A  key  responsibility  of  the  SDM  with  the  SIM  is  to  manage  this  complex  process. 

A  typical  design  cycle  will  last  from  6  to  10  weeks.  Work  in  most  disciplines  will  be  continuous.  However,  at 
certain  periods  the  activity  in  any  particular  discipline  may  become  critical  to  the  overall  schedule.  The  bold  lines 
in  Figure  5-1  show  the  nominal  critical  path  through  the  design  cycle.  The  start  and  end  points  for  a  given  cycle 
are  somewhat  arbitrary  since  this  is  a  continuous  process.  The  figure  starts  with  the  issue  of  the  configuration 
baseline  for  the  nth  iteration  of  the  model.  The  configuration  baseline  represents  the  ship  configuration  that  will 
form  the  basis  for  analyses  and  trade-studies  during  the  nlh  iteration  of  the  design. 

Typically  a  “drawing  board”  review  is  held  after  each  design  iteration.  This  examines  the  current  state  of  the 
design  as  reflected  in  the  Computer-Aided  Design  (CAD)  drawings,  three -dimensional  model,  and  trade  studies 
conducted  during  that  iteration.  A  determination  is  made  as  to  which  changes  will  be  incorporated  into  the  design 
and  which  trade  studies  need  to  be  conducted  during  the  next  iteration.  The  review  and  design  integration 
process,  along  with  scheduling  and  configuration  management  issues,  is  typically  delegated  to  the  DIM. 
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Figure  5-1.  The  Design  Process 


Critical  path  activities  generally  include  development  of  the  weight  report  and  stability  analysis.  A  preliminary 
“quick  look”  weight  report  can  be  issued  approximately  12  working  days  after  release  of  the  baseline 
configuration.  The  final  weight  report  for  the  nth  design  cycle  takes  approximately  25  working  days.  The  stability 
analysis  takes  approximately  five  working  days. 

Costing  efforts  will  begin  starting  with  the  weights  “quick  look”  report  and  end  approximately  seven  working 
days  after  issuance  of  the  final  weight  report  for  each  iteration. 

When  the  weight  and  stability  reports  for  the  nth  cycle  have  been  completed,  a  configuration  review  will  be  held. 
The  purpose  of  the  review  is  to  evaluate  the  changes  proposed  for  the  (n+l)th  iteration.  For  the  next  several 
weeks,  the  arrangement  and  design  for  the  (n+l)th  configuration  are  performed  while  in-depth  analyses  of  the  nth 
configuration  go  forward.  At  the  end  of  this  period  the  general  arrangement  drawings  for  the  (n+l)th  cycle  are 
frozen  and  the  above  process  repeats.  Experience  has  shown  that  multiple  design  cycles  are  required.  The  first 
few  cycles  typically  result  in  insufficient  or  unbalanced  performance,  do  not  meet  required  cost  or  performance 
objectives,  contain  significant  design  flaws,  or  contain  unacceptably  risky  features. 
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This  discussion  is  representative  of  the  timing  and  sequencing  once  all  technical  efforts  are  up  to  speed  and  the 
Design  Team  has  been  firmly  established.  As  the  design  progresses,  schedules  should  be  periodically  updated 
and  distributed  to  all  team  members  to  communicate  when  critical  deliverables  are  needed  to  support  the  overall 
process.  The  SDM  must  pay  close  attention  to  critical  path  activities.  The  SDM  needs  to  continuously  assess  the 
readiness  of  each  discipline  to  feed  the  associated  analysis.  It  is  also  a  key  responsibility  of  the  SDM  to  direct 
those  changes  and  trade-offs  that  will  lead  to  design  convergence  while  meeting  established  performance  and  cost 
objectives. 

Design  development  depends  primarily  on  two  types  of  activities  and  transactions  (or  transfers)  of  data  between 
them:  DEFINITION  and  EVALUATION.  While  the  order  of  execution  and  the  number  of  repetitions  of  these  basic 
activities  and  transactions  vary  widely,  the  basic  elements  are  largely  the  same  from  ship  to  ship,  time  to  time,  and 
organization  to  organization. 

DEFINITION  is  the  activity  of  developing  an  arrangement  of  the  physical  components  of  a  ship  as  a  trial  solution 
to  the  set  of  requirements  and  constraints  facing  the  designer  at  any  particular  stage.  DEFINITION  activities  define 
what,  in  the  end,  will  be  the  products  of  design,  the  tangible  elements  of  the  resulting  ship  -  what  will  be  built. 
DEFINITION  includes  hull  shaping  and  subdivision  (molded  DEFINITION),  structural  arrangement,  component 
selection  and  placement,  and  distributive  system  design  and  arrangement.  These  are  accomplished  at  successive 
levels  of  DEFINITION  as  the  design  is  “filled  in.” 

Table  5-1.  Types  and  Levels  of  Definition 


Hull  Shaping  & 
Subdivision 

Structural 

Arrangement 

Component  Selection 
&  Placement 

Distributed  System 
Design  and 
Arrangement 

Parametric 

Parametric 

Parametric 

Parametric 

Schematic 

Schematic 

3D  Surface  Definition 

Stiffener  Location 

Diagrammatic 

Diagrammatic 

3D  Space  Reservation 

3D  Space  Reservation 

3D  Space  Reservation 

Manufacturing  Detail 

Manufacturing  Detail 

Manufacturing  Detail 

Manufacturing  Detail 

Maintenance  Detail 

Every  component  must  eventually  be  located  on  some  structural  elements  which  themselves  are  located  relative  to 
some  molded  surface.  Part  of  design  completion  is  having  all  DEFINITIONS  consistently  derived  from  the  same 
master  model  or  common  geometry  model. 

General  puipose  CAD  software  is  predominately  used  for  the  development  of  ship  DEFINITION,  although 
Advanced  Surface  Ship  Evaluation  Tool  (ASSET)  and  special  purpose  hull  development  software  such  as 
FASTSHIP  contribute  substantially  to  DEFINITION.  Distributed  systems  are  typically  designed  with  discipline 
specific  tools.  Where  multiple  CAD  systems  are  in  use  for  design  development,  or  where  the  Design  Team 
wishes  to  capitalize  on  DEFINITION  information  from  previous  ships,  the  SDM  will  be  confronted  with  data 
transfer  issues. 

There  are  International  Organization  of  Standardization  (ISO)  industry  standards  (ISO  10303  STEP)  in  place 
specifying  content  and  format  for  exchanging  ship  product  model  data.  Prototype  translators  have  been  built  for 
several  CAD  systems,  but  they  are  not  generally  commercially  available  at  present.  The  ISO  standards  are 
applicable  to  CAD  to  computer-aided  engineering,  CAD  to  Product  Data  Model  (PDM),  and  CAD  to  Enterprise 
Resources  Planning  (ERP)  data  transfer  as  well  as  CAD  to  CAD  data  transfer.  Increasingly  they  will  be  required 
for  ship  product  model  data  delivery  under  developing  DoD  and  DoN  policy.  Currently,  cooperating  engineering 
organizations  can  pass  a  great  deal  of  useful  geometric  and  engineering  information  between  systems.  However, 
there  is  plenty  of  grist  for  contention,  obstruction,  and  fault-finding  for  organizations  not  motivated  to  cooperate. 
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EVALUATION  is  the  activity  of  estimating  or  forecasting  the  characteristics,  performance,  cost,  schedule,  or  risk 
associated  with  a  particular  DEFINITION.  DEFINITION  defines  what  will  be  built.  EVALUATION  explains  why  the 
specific  design  will  be  built.  EVALUATION  of  different  characteristics  is  done  primarily  by  computer  tools, 
including  spreadsheets,  visualization  tools,  computer-aided  engineering  tools,  and  simulations.  Model  and  full- 
scale  testing  are  the  ultimate  forms  of  EVALUATION. 

Each  EVALUATION  requires  DEFINITION  information  as  input.  Particular  EVALUATIONS  may  require  a  minimum 
level  of  DEFINITION  as  input.  Some  examples: 

•  Stability  Analysis.  A  single  program.  Ship  Hullform  Characteristics  Program  (SHCP)  and  derivatives, 
is  used  at  all  stages  of  design.  It  requires  three-dimensional  surface  definition  but  uses  parametric 
distributions  of  structural,  component,  and  systems  information. 

•  Survivability  Analysis.  One  program,  FastSVM,  is  used  in  early  stage  design  to  provide  estimates 
based  upon  ship  characteristics  and  parameters.  Another  program.  Ship  Vulnerability  Model 
(SVM)/Advanced  Survivability  Assessment  Program  (ASAP),  requires  structural  arrangement  and 
system  arrangement  information  to  model  blast  effects  and  system  deactivation.  The  former  can  be  run 
at  any  stage  of  design.  The  latter  cannot  be  run  until  definition  has  progressed  to  the  point  where  the 
required  information  is  available. 

Other  than  these  information-availability  limitations,  there  is  no  restriction  or  pre-determined  order  in  which 
EVALUATIONS  must  be  run.  Individual  designs  will  follow  different  paths  depending  upon  a  variety  of 
considerations.  However,  most  of  the  EVALUATIONS  will  be  used  at  some  time  during  each  design. 

The  SDM/SIM  will  have  given  considerable  thought  to  the  EVALUATIONS  needed  for  the  particular  program  and 
phase.  In  cooperation  with  the  respective  TWH,  the  SDM  must  consider  the  availability  and  suitability  of  the 
software  tool  to  be  used  to  support  each  EVALUATION,  both  by  the  design  agent  during  design  and  by  the  Navy 
during  design  review  and  ship  certification.  In  cooperation  with  the  respective  TWH,  the  SDM/SIM  must 
persuade  the  Program  Office  to  make  timely  investments  in  critical  analysis  tools  to  support  EVALUATION 
requirements  of  later  design  stages. 

Each  DEFINITION  -  EVALUATION  iteration  will  require  labor  and  time  to  pull  configuration  information  from  a 
DEFINITION  and  prepare  it  for  use  in  an  EVALUATION.  Frequently,  translation  or  reformatting  is  necessary.  Most 
EVALUATION  programs  rely  upon  an  analysis  model  that  is  different  in  form  from  CAD  models  used  for 
DEFINITION. 

A  quick  measure  of  the  efficiency  of  a  design  process  is  the  length  of  time  and  the  amount  of  labor  required  to 
complete  a  DEFINITION  -  EVALUATION  iteration.  For  example,  in  the  early  1980s  signature  EVALUATIONS 
required  months  to  complete,  so  long  that  it  was  extremely  difficult  to  incorporate  the  design  modifications 
suggested  by  the  results.  Over  the  two  decades  since,  the  cycle  time  has  been  reduced  to  days  and  hours,  allowing 
many  alternatives  to  be  evaluated  and  allowing  designs  to  be  shaped  for  reduced  signatures. 

The  principal  information  needed  by  an  EVALUATION  is  ship  DEFINITION.  An  EVALUATION  may  also  call  for  the 
results  of  another  EVALUATION  as  input.  For  example,  a  structural  loads  estimation  program  may  require  the 
results  of  a  ship  motion  program  as  input.  However,  the  amount  of  information  to  be  transferred  and  the  labor 
required  is  generally  minimal  compared  to  the  DEFINITION  -  EVALUATION  transaction. 

There  is  also  a  need  to  return  the  results  of  an  EVALUATION  for  consideration  in  subsequent  definitions.  Again, 
this  is  a  lightweight  TRANSACTION.  Consider  the  substantial  amount  of  information  required  to  convey  a 
structural  DEFINITION  for  a  grillage  EVALUATION.  Compare  that  to  the  feedback:  “Use  the  next  larger  size  for 
longitudinal  stiffeners.” 

NAVSEA  is  rapidly  moving  to  Leading  Edge  Architecture  for  Prototyping  Systems  (LEAPS)  as  a  standard  means 
for  facilitating  DEFINITION  -  EVALUATION  iterations,  for  storing  EVALUATION  results  for  later  reference,  and  for 
design  configuration  management.  LEAPS  is  suitable  as  a  design  environment  and  will  be  the  principal 
mechanism  for  importing  design  agents’  designs  to  NAVSEA  for  warrant  holder  review. 
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A  fuller  discussion  of  this  view  of  the  ship  development  process  and  associated  tools  is  contained  in  the  paper 
1CCAS  2002,  “An  Activity/Transaction  Model  for  Ship  Design  Development.” 

5.1.1  Impact  Of  Design  on  Total  Ownership  Cost.  As  the  design  proceeds  and  ship  requirements  and 
resulting  characteristics  become  better  defined,  much  of  the  ultimate  Total  Ownership  Cost  (TOC)  is  determined. 
Ship  design  has  a  major  impact  on  most  TOC  components,  including  manning,  fuel,  maintenance,  and  disposal 
cost.  Typically,  the  funding  allocated  to  define  and  design  the  ship  is  grossly  disproportionate  to  the  cost  of 
construction  and  operations.  The  design,  which  expends  less  than  5%  of  the  total  life  cycle  cost  of  the  ship, 
largely  determines  the  other  95%  of  the  TOC.  See  the  figure  below. 
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Figure  5-2.  Design  Phase  Influence  of  Total  Cost  of  Ownership 

5.1.2  Design  Margins  and  Service  Life  Allowances.  To  accommodate  changes  to  the  ship’s  configuration 
during  future  iterations  of  the  design,  as  well  as  uncertainties  regarding  the  material  and  equipment  in  the 
constructed  ship,  all  ship  designs  must  incorporate  margins  and  allowances  consistent  with  the  evaluation  of  risk. 
This  is  a  key  SDM  responsibility.  The  SDM  must  balance  technical  risk  mitigation  against  increased  procurement 
cost.  As  shown  in  Figure  5-3,  the  level  of  risk  is  tied  to  the  probability  that  the  System  Capacity  is  sufficient  to 
serve  the  predicted  load,  including  the  variability  of  the  load  estimate.  As  shown  in  Figure  5-4,  a  smaller  variance 
in  the  load  estimate,  resulting  from  higher  design  fidelity,  can  enable  a  reduction  in  design  margin.  Managing  the 
rate  in  which  the  margin  is  allowed  to  reduce  as  the  design  matures  is  an  important  SDM  responsibility.  To  aid 
the  SDM  in  determining  the  adequacy  of  remaining  margin,  the  Design  Team  should  estimate  the  variability  of 
the  load  predictions.  Appendix  A  provides  selected  references  on  application  of  design,  build,  and  service  life 
margins. 

For  most  ship  designs,  it  is  prudent  to  apply  margins  to  weight  and  KG;  distributed  system  capacity  such  as 
electric  power,  chill  water,  and  network  loading;  accommodations;  arrangeable  area;  and  propulsion  power. 

Margin  usage  is  a  key  design  metric  that  can  necessitate  major  redesign  efforts. 


5-5 


S9800-AC-M  AN-010 


Additionally,  service  life  allowance  requirements  are  typically  levied  on  ship  designs  to  accommodate  the 
installation  of  changes  in  the  ship  over  the  service  life  of  the  ship.  Typical  areas  for  which  a  service  life 
allowance  is  specified  include  weight,  KG,  and  distributed  system  capacity. 
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Figure  5-3.  Predicted  Load  Probability  Density  and  System  Capacity  Risk 
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Figure  5-4.  Impact  of  Improved  Predicted  Load  on  System  Capacity  Risk 
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5.1.3  Systems  Engineering  Process.  SDMs  and  SIMs  should  be  NAVSEA’s  experts  in  the  conduct  of 
systems  engineering.  Per  the  DoD  and  SECNAV  instruction  5000  series,  system  engineering  should  be  a 
foundation  for  ship/system  design.  There  is  a  wealth  of  information  on  the  subject  available  throughout  the 
defense  acquisition  community.  Section  2.1  cites  websites  and  applicable  references.  See  also  Appendix  A  for 
selected  references  related  to  the  process.  The  challenge  for  the  SDMs  and  SIMs  is  to  translate  this  guidance  into 
actionable,  practical  advice  for  managing  a  ship/system  design. 

Figure  5-5  shows  the  systems  engineering  design  process  featuring  three  stages:  requirements  analysis,  functional 
analysis/allocation,  and  systems  design.  System  analysis  and  control  is  continuously  applied  to  keep  the  process 
on  track.  The  purpose  of  the  requirements  analysis  effort  is  to  properly  identify  and  document  the  user’s 
requirements  and  translate  those  requirements  into  a  set  of  technical  requirements  for  the  system.  During 
functional  analysis/allocation,  the  requirements  identified  in  requirements  analysis  are  translated  into  a  functional 
decomposition  that  describes  the  product  in  terms  of  an  assembly  of  configuration  items  where  each  configuration 
item  is  defined  by  what  it  must  do,  its  required  performance,  and  its  interfaces.  Finally,  during  design  synthesis, 
specific  hardware,  software,  and  “humanware”  (that  is,  human  operators  considered  as  configuration  items  in  the 
functional  analysis)  are  defined  to  meet  the  requirements  of  the  configuration  items.  Systems  analysis  and  control 
provides  the  technical  management  activities  necessary  to  keep  the  entire  process  moving  on  schedule  with 
acceptable  performance  and  cost. 


This  is  an  idealized  process  and  it  is  typically  interpreted  to  be  serial  and  iterative.  In  practical  application,  all  of 
the  components  occur  concurrently.  See  Appendix  PP  (hyperlink)  for  an  expanded  discussion  of  the  application 
of  system  engineering. 
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5.1.4  Establishing  Requirements  and  Constraints.  Ship  design  tasks  relating  to  ship  acquisition  programs, 
including  requests  for  feasibility  studies,  are  generally  accompanied  by  a  formal  OPNAV  request  and  explicit 
statement  of  requirements.  The  SDM  and  SIM  are  essential  participants  in  requirements  definition,  making 
certain  requirements  are  complete  and  executable. 

The  CDD  and  Capability  Production  Document  (CPD)  represent  negotiated  agreements  between  the  Program 
Office  and  Sponsor  for  minimum  ship  performance  and  maximum  cost.  They  do  not  provide  adequate  direction 
for  design  and  are  not  written  as  specifications.  For  Navy  Designs,  the  SDM  should  develop  and  issue  detailed 
design  guidance  under  his  signature  to  the  Design  Team.  For  Contractor  Designs,  the  acquisition  strategy  may 
dictate  development  of  specifications  or  a  circular  of  requirements  for  incorporation  in  the  design  contract. 

The  task  of  translating  requirements  into  design  direction  should  begin  with  consultation  with  the  project  SEMs 
and  Program  Office  on  the  design  philosophy.  Discussions  should  address  topics  like  cost  and  performance 
targets,  design  process  metrics,  interoperability,  open  systems,  standardization,  risk  management,  technology 
insertion,  data  management,  and  design  certification.  The  applicability  of  NAVSEA  design  standards,  practices, 
and  policies  should  be  addressed. 

5.1 .4.1  Requirements  Traceability.  Software  like  DOORS®,  RTM®,  SLATE®,  and  Requisite  Pro®  have  been 
successfully  employed  to  verify  the  flow  down  of  requirements  from  the  Initial  Capabilities  Document  (ICD)  to 
the  CDD  to  the  TEMP,  specifications,  and  other  contracting  documentation.  Requirements  from  other  sources 
such  as  statutes,  OPNAV  instructions,  and  regulations  should  also  be  traced.  Additionally,  every  derived 
requirement  should  be  tracked  and  traced  to  the  functional  allocation  or  synthesis  decision  that  spawned  it. 

Verifying  consistency  of  the  various  program  documents  is  also  possible  through  the  use  of  requirements 
traceability  software.  Requirements  traceability  and  its  tools  are  a  necessary  part  of  the  systems  engineering 
process,  but  these  processes  and  tools,  in  themselves,  do  not  constitute  systems  engineering.  Requirements 
analysis,  functional  allocation,  and  design  synthesis  must  all  work  together  to  ensure  the  design  will  work  and 
meet  customer  requirements.  Please  see  Figure  5-6. 

Note  that  the  Commander,  Operational  Test  and  Evaluation  Force  (COMOPTEVFOR)  will  be  developing  a 
comparable  database  -  an  Operational  Testing  Framework  -  to  support  their  planning  and  conduct  of  Operational 
Test  and  Evaluation. 
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Figure  5-6.  Example  of  Typical  Requirements  Traceability  Flow 

5. 1.4. 2  Study  Guides  and  Design  Kickoff  Meetings.  The  SDM  is  required  to  prepare  and  publish  by  official 
serialized  memorandum  a  study  guide  to  document  the  requirements  for  a  study.  This  is  a  critical  tool  for 
controlling  the  technical  discussion  and  managing  expectations.  A  kickoff  meeting  should  be  conducted  with  the 
Program,  other  stakeholders,  and  where  appropriate,  SEA  05C.  The  study  guide  should  be  a  focus  of  this 
meeting.  It’s  usually  best  not  to  start  the  effort  until  the  study  guide  has  80  percent  acceptance  and  definition. 
This  will  prevent  wasting  resources  and  time. 

5. 1.4. 3  Development  of  Specifications  and  Other  Contract  Content.  Requirements  definition  activity 
naturally  evolves  into  the  SDM  leading  the  Navy  effort  on  preparation  of  a  Specification  for  the  ship,  as  well  as 
drafting  the  SOW  and  DRL  design  content  for  the  DD&C  RFP. 

Whether  the  Navy  or  industry  prepares  the  Specification,  the  SDM  is  responsible  for  its  completeness  and 
technical  acceptability.  SDMs  should  guide  the  process  for  selecting  an  acceptable  combination  of  design 
standards  and  verification/validation  requirements  for  Navy  approval  in  the  Specification.  Appendix  A  provides 
selected  references  offering  guidance  related  to  development  of  Specifications. 

The  SDM’s  role  in  Specification  development  is  first  to  establish  an  overall  approach  in  conjunction  with  the 
acquisition  strategy.  A  “spec  tree”  showing  the  organization  and  hierarchy  of  the  Specifications  is  then 
developed.  Specification  section  development  responsibilities  and  technical  authorities  are  defined.  Review  and 
certification  processes  are  established.  The  Program  Office  should  have  a  significant  role,  often  co-equal  to  the 
SDM,  in  the  review  process. 
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Figure  5-7.  Specification  Tree 

The  SDM  and  SEA  05S  must  instruct  the  Design  Team  on  Specification  preparation  in  order  to  get  clarity  and 
consistency  in  the  finished  product.  A  variety  of  training  presentations  have  been  developed  for  previous  efforts. 

The  Specification  must  be  written  to  ensure  each  requirement  is  measurable  and  has  a  corresponding  and 
explicitly  identified  test.  It  is  common  for  a  test  section  to  be  written  in  the  same  sequence  with  a  paragraph 
numbering  scheme  corresponding  to  the  main  requirements  section. 

Duplication  of  content  between  Specification  sections,  the  Specifications  and  SOW,  and  the  Specifications  and 
any  other  contracting  documents  should  be  avoided  to  prevent  the  introduction  of  inconsistencies.  The  SOW 
should  define  what  the  contractor  will  be  required  to  do,  and  the  Specifications  should  provide  the  criteria. 

Should  the  T-ship  be  required  to  be  classed  by  ABS,  the  relevant  ABS  Rules  will  form  a  major  set  of  invoked 
criteria.  It  is  extremely  important  to  ensure  that  care  is  taken  to  deconflict  the  Specifications  with  the  invoked 
Rule  sets. 

The  SDM  will  conduct  Specification  reading  sessions  during  Contract  Design,  a  major  undertaking  and  extremely 
time-consuming  effort.  For  new  designs,  two  reading  sessions  are  held,  the  SEM  Reading  Session  and  the  Final 
Contract  Design  Reading  Session.  The  SEM  Reading  Sessions  will  be  held  to  ensure  that  the  design  reflects  the 
requirements  of  the  CDD,  that  no  major  technical  inconsistencies  exist,  and  that  the  required  system  interfaces  are 
accounted  for  prior  to  configuration  control  of  the  Specification,  Contract  Drawings,  and  Project-Peculiar 
Documents.  These  normally  proceed  from  general  to  more  specific  requirements  sections,  with  the  corresponding 
testing  sections  read  in  parallel  and  the  HSI,  safety,  DRL,  GFE/GFI,  contract  SOW,  and  other  considerations 
reviewed  for  each  section.  A  typical  Final  Specification  Reading  Session  lasts  about  six  weeks.  Sections  are 
traditionally  “read”  beginning  with  the  General  Sections,  SWBS  Group  100,  SWBS  Group  500,  SWBS  Group 
200,  SWBS  Group  300,  SWBS  Group  400,  SWBS  Group  700,  and  SWBS  Group  600.  The  SDM  can  alternately 
employ  a  matrix  to  track  the  interdependency  of  Specification  sections  and  identify  the  optimal  order  for  reading 
Specification  sections. 
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After  Certification  by  the  TWHs  of  the  Specification  and  PPDs  and  Contract  Drawings,  the  SDM  will  present  the 
completed  Technical  Data  Package  to  SEA  05  via  SEA  05D/V  for  approval  and  signature  at  the  end  of  Contract 
Design.  SEA  05  will  rely  to  a  large  degree  on  the  SDM’s  appraisal  of  the  Specification  in  deciding  to  approve  it. 

The  Contract  will  establish  order  of  precedence  between  the  SOW,  Specifications,  and  other  contract  attachments. 
The  Contract  should  also  establish  an  effective  date  for  all  references. 

Other  lessons  learned  include  the  need  for: 

•  Careful  definition  of  an  approach  for  Specification  content  and  development  that  suits  the  acquisition 
strategy 

•  Clarity  in  DRLs  to  ensure  that  the  specific  information  needed  is  received 

•  Reviews  of  drawings,  PPDs,  other  contractual  documentation,  and  associated  references  conducted 
with  as  much  effort  as  and  in  parallel  with  the  Specifications 

•  Agreement  and  publication  of  criteria  and  content  for  review  comments 

•  Strong  management  of  the  support  provided  by  organizations  such  as  PEO  C4I,  PEO  IWS,  NAVAIR, 
and  NSWC  DD 

•  Resolution  and  documentation  of  design  issues  through  a  design  decision  memorandum  or  equivalent 
process 

•  Resolution  and  documentation  of  Specification  and  other  contractual  documentation  changes  through  a 
Naval  Adjudication  Board  or  equivalent  process 

There  have  been  a  number  of  terms  used  for  ship  Specifications  but  we  are  currently  trying  to  limit  usage  to  two 
types.  The  term  “Ship  Systems  Specification”  should  be  used  for  the  Specification  developed  for  the  conduct  of 
design  efforts  prior  to  Detail  Design  and  Construction  and  the  term  “Shipbuilding  Specification”  should  be  used 
for  the  Specification  developed  for  the  conduct  of  Detail  Design  and  Construction. 

The  preferred  method  of  stating  requirements  in  a  Ship  Systems  Specification  is  in  terms  of  the  required  results 
with  verifying  compliance,  but  without  stating  the  methods  for  achieving  the  required  results.  A  Ship  Systems 
Specification  defines  the  performance  and  functional  requirements  of  an  item,  the  environment  in  which  it  shall 
operate,  and  interface  and  interchangeability  characteristics.  A  Ship  Systems  Specification  also  specifies  and 
tailors  the  standard  technical  architecture  or  “building  code(s)”  that  are  to  provide  the  foundation  for  the  design. 
Example  standard  technical  architectures  include  the  ABS  Steel  Vessel  Rules. 

A  Ship  Shipbuilding  Specification  contains  the  construction  materials,  items,  and  component  requirements  which 
pertain  to  their  selection,  installation,  shipboard  performance,  shipboard  inspection  and  tests,  and  pre-installation 
handling,  inspection,  and  tests  performed  by  the  Shipbuilder.  Government  or  industry  Specifications  and 
standards  invoked  in  the  Shipbuilding  Specification  delineate  requirements  for  material,  components,  and 
systems.  Performance  and  functional  requirements  that  were  in  the  Ship  System  Specification  may  have  been 
further  decomposed  during  Preliminary  and  Contract  Design  into  design  solutions,  such  as  a  specific  hull  form 
and  arrangement,  that  are  included  in  the  Shipbuilding  Specification.  In  addition,  further  tailoring  of  the  standard 
technical  architecture  may  be  included  if  those  exceptions  are  known  during  design. 

The  Ship  System  Specification  may  be  used  as  a  contract  Specification  when  the  acquisition  strategy  calls  for  a 
contractor  to  conduct  Concept,  Pre -Preliminary,  Preliminary,  or  Contract  Design. 
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Specifications  shall  normally  be  structured  in  accordance  with  ESWBS  as  follows: 

•  000  General  Guidance  and  Administration 

•  100  Hull  Structure 

•  200  Propulsion  Plant 

•  300  Electrical  Plant 

•  400  Command  and  Surveillance 

•  500  Auxiliary  Systems 

•  600  Outfit  and  Furnishings 

•  700  Armament 

Numbers  for  major  groups  have  double  zeros  (000,  100,  200);  subgroups  end  with  a  single  zero  (110,  120,  320); 
and  subgroup  elements  do  not  end  with  a  zero  (111,  121,  321). 

Hierarchy  of  requirements  within  a  system  section  should  be  organized  in  accordance  with  the  following  content 
layout: 

•  Number  and  Title  -  ESWBS  number  and  title  of  section. 

•  Definitions  -  Definitions  of  terms  not  contained  in  the  dictionary  that  are  unique  to  and  used  in  that 
section  (Only  if  necessary  for  clarity.). 

•  General  Requirements  -  Requirements  that  apply  to  all  systems,  equipment,  and  components  specified 
in  the  section  (Always  before  detail  requirements). 

•  Detail  Requirements  -  Requirements  describing  the  systems,  equipment,  and  components,  and  their 
required  performance  capabilities.  Reference  to  applicable  equipment  and  material  specifications. 

•  Shock  -  The  specific  show  grade  defined  in  Section  072  and  unique  shock  qualification  requirements 
for  systems,  equipment,  and  components.  Where  different  shock  qualification  requirements  apply  to 
different  systems  or  parts  of  a  system,  the  boundaries  of  the  various  shock  levels  shall  be  clearly  and 
specifically  defined. 

•  Technical  Documentation  -  The  general  requirements  for  drawings,  manuals,  and  other  technical 
documentation  shall  be  contained  in  Sections  085  and  086.  Specific  technical  documentation 
requirements  not  covered  in  Sections  085  and  086  shall  be  included  in  this  paragraph.  Contract  data 
tasking  statements  shall  be  included  to  identify  the  technical  documentation  to  be  prepared  by  the 
Shipbuilder.  Each  deliverable  item  shall  be  listed  here  and  in  the  DRL. 

•  Tests  -  This  section  shall  include  pre  Stage  2-7  test  requirements  for  subsystems  or  components  where 
there  is  a  high  risk  associated  with  performing  the  test  after  delivery  to  the  shipyard  or  installation  on 
the  ship.  All  shipboard  testing  to  demonstrate  compliance  with  the  Specification  requirements  by  the 
delivered  Shipbuilder  and  Government  furnished  equipments,  subsystems,  and  systems  shall  be 
specified  by  the  Shipbuilder  test  program  covered  in  Sections  090  through  095. 
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5. 1.4. 4  Use  Of  Performance  Specifications.  Under  the  DoD  and  SECNAV  5000  series  instructions, 
specifications  for  the  procurement  of  new  systems  and  subsystems  shall  be  written  in  performance-based  terms 
(i.e.,  DoD  performance  specifications,  commercial  item  descriptions,  and  performance-based  non-government 
standards)  to  the  extent  practicable.  A  waiver  is  no  longer  required  in  order  to  invoke  military  specifications  or 
standards,  but  its  use  should  be  limited  to  government-unique  requirements  and  interface  requirements. 

Since  the  military  standards  and  specifications  were  minimized  for  LPD  17  and  subsequent  procurements, 
significant  strides  have  been  made  in  updating  Navy  ship  design  procedures  to  incorporate  the  most  advantageous 
level  of  military  standards  and  specifications.  Although  current  policy  favors  “performance  specifications,” 
current  System  Specifications  are  appropriately  a  mix  of: 

•  Performance  language 

•  Citations  of  commercial  standards,  and,  sometimes,  classification  requirements 

•  Reference  to  a  few  selected  military  specifications  and  standards,  like  shock,  where  there  is  no 
commercial  equivalent 

•  Detailed  specifications  and  installation  control  drawings  for  areas  where  the  Navy  has  customer 
preference  and/or  special  knowledge,  such  as  combat  systems,  survivability,  underway  replenishment, 
and  aviation 

5. 1.4. 5  ABS  Naval  Vessel  Rules  and  ABS  Steel  Vessel  Rules.  The  development  of  the  Naval  Vessel 
Rules  (NVR)  was  begun  in  the  early  90s  to  simplify  the  naval  ship  design  process.  It  was  restarted  with  the 
advent  of  acquisition  reform,  lack  of  funding  for  updating  standards,  and  the  desire  to  modernize  military 
standards  and  specifications.  Some  combatant  Ship  Specifications  such  as  DDG  1000  and  LCS  were  calling  out 
applicable  sections  of  the  NVR  followed  by  any  program-specific  amplifications  or  modifications.  However,  a 
decision  has  been  made  to  limit  the  use  of  ABS  in  the  classification  of  surface  combatants.  Transition  plans  are  in 
place  to  ramp  down  ABS  involvement.  Applicable  NVR  content  is  to  be  incorporated  into  a  Navy  publication. 
Further  detail  will  be  provided  in  the  next  revision  to  this  manual. 

The  ABS  role  for  MSC  ships  (T-ships)  remains  unchanged.  They  will  generally  follow  modified-commercial 
standards  including  ABS  Steel  Vessel  Rules. 

5.1 .4.6  Commercial  VS.  Navy  Construction.  In  general,  Navy  combatant  ship  construction  methods  are  more 
expensive  than  commercial  ship  production.  This  difference  is  largely  due  to  the  differing  approaches  to 
survivability  between  commercial  ships  and  naval  combatants.  Commercial  ships  are  designed  to  survive  damage 
from  typical  accident  scenarios  such  as  groundings,  collisions,  and  main-space  fires.  If  the  damage  cannot  be 
contained  within  a  few  hours,  doctrine  calls  for  the  merchant  crew  to  abandon  ship.  Since  loss  of  the  ship  and 
cargo  are  covered  by  insurance,  preservation  of  life  is  of  paramount  concern.  Naval  warships,  on  the  other  hand, 
are  expected  to  survive  weapons  effect  damage  and  be  capable  of  restoring  their  primary  mission,  to  continue  the 
fight.  Different  classes  of  ships  are  provided  different  levels  of  survivability  based  on  their  projected  operational 
environments.  For  example,  although  MSC  T-ships  are  not  expected  to  operate  in  high  threat  areas,  their 
increased  complexity  and  survivability  features  are  more  expensive  than  commercial  single  product  ships. 
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5.1 .4.7  Modified  Repeats.  Modifying  an  existing  design  to  produce  a  new  ship  with  different,  presumably 
enhanced,  capabilities  is  a  practice  that  has  been  followed  for  many  ship  types.  In  2004,  the  LHA(R)  program 
was  redirected  to  develop  a  Contract  Design  that  was  very  closely  derived  from  the  LHD  8  design.  During  the 
Preliminary  Design  and  Contract  Design  development,  the  LHA(R)  configuration  management  process  was 
tightly  coupled  to  the  configuration  management  process  for  the  LHD  8.  Design  decisions  were  evaluated  with 
one  of  the  key  considerations  being,  “How  is  the  issue  being  addressed  on  the  LHD  8?”  Changes  to  major  blocks 
and  assemblies  were  kept  to  a  minimum  to  reduce  non-recurring  engineering  costs.  Shipbuilder  involvement  was 
emphasized  so  that  every  change  was  carefully  evaluated  from  a  design  and  production  cost  standpoint.  When  the 
LHA(R)  is  acquired  following  the  modified  repeat  strategy,  a  new  ship  will  be  delivered  with  the  required 
capability,  yet  engineering  costs  will  be  minimized  and  operating  similarities  maximized. 

Achievement  of  cost  savings  by  using  a  modified  repeat  strategy  requires  that  a  careful  management  minimizes 
changes  to  the  design,  and,  in  particular,  to  the  production  engineering  and  build  strategy.  Benefits  are  increased 
when  production  can  continue  without  a  significant  gap.  It  is  remarkable  how  small  changes  can  have  significant 
effects  on  the  non-recurring  engineering  required  to  design  a  modified  repeat.  During  the  LHA(R)  design, 
considerable  program  management  attention  was  applied  to  minimize  this.  It  was  clear  to  the  Design  Team  that 
the  Program  Manager  placed  a  high  priority  on  minimizing  changes  that  would  increase  non-recurring 
engineering  costs.  Following  a  modified  repeat  strategy  adds  constraints  that  would  not  apply  to  a  “clean  sheet” 
design  approach.  Before  a  modified  repeat  strategy  is  followed,  the  SDM  must  evaluate  the  effects  on  the  design 
due  to  constraints  imposed  by  minimizing  change.  If  the  mission  of  the  required  ship  differs  significantly  from 
that  of  the  “parent”  ship,  then  the  cost  associated  with  a  new  design  may  be  less  than  modifying  an  existing  one. 
The  changes  may  be  so  substantial  that  production  benefits  do  not  accrue  to  the  same  degree.  Similarly,  the 
mission  requirements  may  be  more  effectively  achieved  by  a  new  design  rather  than  through  a  modified  repeat 
approach.  Such  considerations  should  be  addressed  in  the  earlier  phases  of  concept  and  feasibility  assessment. 

See  Naval  Engineers  Journal,  May  1983  paper  “Repeat  Ship  Designs  Facts  and  Myths”  by  Phil  Covich  and 
Michael  Hammes  (hyperlink). 

5.1 .4.8  Conversions.  Conversions  of  existing  ships  have  been  accomplished  to  enhance  or  completely  alter 
their  mission  capabilities  in  order  to  meet  new  requirements.  There  are  three  major  motivations  for  this  approach: 

•  Rapid  delivery  of  a  ship,  when  re-use  of  an  existing  hull,  propulsion  plant,  and  other  major  systems 
minimizes  the  engineering,  material,  and  schedule  requirements  so  that  the  desired  ship  can  be 
produced  more  quickly  than  if  a  new  ship  were  built  “from  the  keel  up”. 

•  Maximizing  commonality  with  other  ships. 

•  Minimizing  cost  by  re-use  of  existing  components. 
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Balancing  the  positive  aspects  of  conversions  are  the  obvious  negatives  that  must  be  considered: 

•  Converting  ships  to  meet  new  mission  requirements  results  in  re-use  of  old  material,  designs,  and 
technology  rather  than  new  material,  current  design  practice,  and  the  latest  technology. 

•  Conversions  may  involve  unexpected  engineering  or  logistics  challenges. 

•  The  conversion  approach  may  persuade  the  designers  to  accept  engineering  solutions  that  would 
otherwise  not  have  been  considered  attractive,  such  as  use  of  a  steam  plant  for  a  ship  that,  if  designed 
as  a  new  ship,  would  have  been  diesel  propelled. 

•  The  complexity  of  a  conversion  can  result  in  a  ship  that  is  not  as  cost-effective  to  operate  in 
comparison  with  a  new  design. 

•  Remaining  service  life  is  limited  by  retained  systems. 

•  Workforce  efficiency  is  reduced  because  the  majority  of  work  must  be  performed  aboard  ship  in 
conditions  that  minimize  productivity. 

•  The  converted  ship  will  likely  include  compromises  such  as  accepting  certain  system  designs  or 
equipment  selections  due  to  existing  conditions,  rather  than  designing  the  ship  to  incorporate  the  best 
possible  engineering  solutions. 

An  example  of  a  conversion  that  experienced  major  delays,  disruptions,  and  other  problems  is  the  conversion  of 
the  USNS  LCPL  ROY  M.  WHEAT  (T-AK  3016).  During  the  conversion  process,  unexpected  engineering 
problems  were  addressed,  including  structural  issues,  material  readiness  issues,  regulatory  body  issues,  and 
hazardous  materials  mitigation.  These  added  cost,  delayed  production,  and  complicated  the  acquisition.  Other 
new  ships  were  acquired  for  the  same  mission  more  rapidly  and  at  less  cost.  The  WHEAT  conversion  was 
complicated  by  the  facts  that  it  was  originally  a  Ukrainian  ship  built  to  very  different  standards  and  that  there  was 
a  lack  of  documentation  for  many  systems. 

Conversions  can  be  cost-effective  or  desirable  when:  only  limited  changes  are  made  to  an  existing  ship;  when  the 
changes  can  be  implemented  as  modules  or  with  other  means  of  improving  productivity  such  as  the  installation  of 
pre -outfitted  midship  plugs;  or  when  a  new  capability  is  required  more  rapidly  than  new  construction  could 
permit. 

An  example  of  limited  changes  resulting  in  an  attractive  conversion  is  the  use  of  a  T-AGOS  class  ship  as  a  school 
ship  and  as  a  platform  to  investigate  new  propulsion  systems.  In  this  case,  removal  of  towed  array  sensor  systems 
was  easy  to  accomplish  and  minimal  additions  needed  to  be  made.  The  propulsion  system  was  diesel  electric  and 
sufficiently  modern  for  training  purposes. 

The  conversion  of  the  AO-177  through  jumboization  was  an  effective  means  of  increasing  the  Fleet’s  capacity  to 
conduct  refueling.  The  new  capability  was  largely  accomplished  through  the  addition  of  a  plug  and  upgrade  of 
refueling-at-sea  systems.  As  another  example,  building  on  the  success  of  the  LMSR  program,  one  was  converted 
to  provide  maritime  prepositioning  enhanced  (MPF[Ej)  capability.  The  converted  ship  not  only  met  the 
requirements  efficiently,  it  was  rapidly  brought  on  line  and  included  systems  that  were  common  to  the  other  ships 
in  the  LMSR  class. 

The  conversion  of  the  collier  USS  JUPITER  to  the  first  aircraft  carrier,  USS  LANGLEY,  was  an  historic  and 
successful  conversion  that  permitted  experimentation  with  new  capabilities.  Carrier  operations  were  perfected  on 
LANGLEY  and  helped  in  developing  the  requirements  for  the  following  classes  of  aircraft  carriers.  Cargo  ships 
such  as  the  USNS  MARSHFIELD  and  USNS  VICTORIA  were  converted  to  carry  specialized  cargos  in  secure 
environments,  serving  the  government  for  another  lifetime,  as  were  several  range  tracking  ships  such  as  the  USNS 
REDSTONE  and  USNS  OBSERVATION  ISLAND. 
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The  Fiscal  Year  1994  conversion  of  LPH-12  to  MCS  12  was  accomplished  based  on  a  limited  scope  Cost  and 
Operational  Effectiveness  Analysis  and  a  procurement  cost  constraint.  The  converted  ship  fell  short  of  the  15- 
year  service  life  that  was  required  -  largely  due  to  steam  plant  reliability,  availability,  and  maintainability  issues. 

When  ships  are  procured  through  lease  arrangements  or  other  competitive  offerings,  the  conversion  risks  and  life 
cycle  operating  cost  risks  may  be  shifted  away  from  the  government  to  private  industry.  In  such  cases, 
conversions  may  prove  to  be  effective  in  providing  rapid  capability.  Success  with  such  conversions  includes  an 
offshore  supply  boat  converted  to  investigate  well  hydrodynamics  in  support  of  the  TAGS  45  program. 
Unfortunately,  the  WHEAT  and  other  less  successful  conversions  provide  reminders  of  the  problems  that  can  be 
encountered.  Even  if  the  government  can  shift  financial  risk  to  private  industry,  the  needed  capability  may  be 
critical.  If  conversions  are  considered,  special  engineering  studies  and  condition  reports  may  be  called  for  to 
document  material  conditions  and  to  validate  engineering  solutions. 

While  conversions  may  be  attractive  or  worth  considering,  it  is  instructive  to  review  the  LMSR  program  that 
included  both  new  construction  and  conversion  designs  built  to  very  similar  requirements.  Note  that  one  reason 
conversions  were  pursued  was  due  to  industrial  base  level  loading  rather  than  overall  cost-effectiveness.  The  cost 
of  the  SEALIFT  conversions  was  less  than  the  new  construction  designs,  approximately  $220M  versus  $300M 
per  ship.  The  conversion  construction  schedules  (award  to  delivery)  were  on  the  order  of  three  years  in 
comparison  with  the  lead  ship  new  construction  schedule  of  five  years.  The  advantages  of  cost  and  time  were 
offset  by  the  acceptance  of  existing  equipment  and  constraints  imposed  on  the  configurations  due  to  the  existing 
arrangement.  Any  use  of  a  conversion  approach  must  carefully  consider  the  limitations  and  risks  relative  to  the 
potential  benefits  and  time  line  of  military  mission  requirements  for  the  asset. 

5.1.5  Cost  Engineering  and  Producibilitv.  The  cost  and  producibility  engineering  functions  must  be 
recognized  as  important  and  integral  parts  of  the  design  process.  For  economic  effectiveness,  every  design  and 
engineering  decision  must  include  cost  and  producibility  as  pertinent  parameters.  Appendixes  UU  and  TT 
provide  additional  information  on  cost  engineering  ( hyperlink )  and  producibility  ( hyperlink ). 

5.1 .6  Cost  As  art  Independent  Variable.  With  a  Cost  As  an  Independent  Variable  (CAIV)  approach, 
operational  requirements  provided  by  the  customer  are  given  in  terms  of  threshold  and  objective  values.  The 
range  between  these  two  values  provides  the  Program  Manager  with  trade-space  to  match  the  available  funds  with 
the  capabilities  that  can  be  bought  for  that  amount  -  the  total  program  cost  remains  a  constant.  See  Appendix  UU 
(hyperlink). 

5.1.7  Technology  Insertion.  A  ship  acquisition  or  in-service  program  will  very  likely  plan  technology 
development  to  achieve  performance  goals.  Opportunities  for  insertion  of  new  technology  systems,  subsystems 
and/or  components  are  driven  by  affordability  and  the  ability  to  address  expected  threats,  but  also  are  heavily 
influenced  by  the  ability  to  mature  proposed  technology  solutions  in  the  time  available. 

Further  complicating  this  picture,  differing  acquisition  timelines  (e.g.,  varying  by  ship  class),  coupled  with 
technology  maturation  tempos  (e.g.,  varying  by  the  category  of  the  developing  technology,  as  well  as  the 
characteristics  of  the  organizations  developing  them),  tend  to  drive  Science  and  Technology  (S&T)  as  well  as 
R&D  demand  signals  in  a  wide  variety  of  directions.  This  phenomenon  is  not  unique  to  “New  Build”  acquisition 
programs,  but  also  occurs  with  efforts  to  insert  new  technology  during  “Modernizations”  and  “Overhauls”. 

As  a  result  of  the  variable  demands  associated  with  shipbuilding  plans  and  technology  development  writ  large,  a 
number  of  S&T/R&D  programs  across  a  range  of  potential  funding  streams  have  emerged  in  addition  to  the 
traditional  programmed  (“POMed”)  approach.  This  has  led  to  the  present  situation,  wherein  a  variety  of  different 
funding  paths  (various  programs  and  initiatives  referred  to  as  the  “Heinz  57  List”)  are  available  to  enable 
transition  of  ready  technologies,  sufficiently  demonstrated  and  tested,  into  shipboard  usage  with  minimum  risk 
and  additional  cost.  The  variety  of  these  possible  technology  development  paths  provide  the  SDM  myriad 
opportunities  but  should  not  replace  a  technology  development  roadmap  tailored  to  the  scale,  scope,  schedule, 
risk,  and  maturity  of  evolving  technologies  against  solid  program  requirements. 
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A  properly  architected  technology  development  roadmap  therefore  reflects  a  balanced  portfolio  of  funded  efforts. 
Wherein  a  mix  of  less  risky  development  efforts  with  greater  likelihood  of  incremental  improvement  over  the 
present  state,  is  balanced  against  riskier  efforts  that  may  provide  significant  advancement  in  capability.  In 
developing  this  plan,  the  SDM  should  consult  with  technologists  and  managers  familiar  with  various  funding 
streams  to  identify  and  quantify  risk  levels,  technology  off-ramps,  and  budget-based  development,  test,  and 
evaluation  events. 

Once  the  roadmap  is  laid  out  and  agreed  upon  with  the  organizations  developing  the  technologies  (Office  of 
Naval  Research  (ONR),  Defense  Advanced  Research  Projects  Agency  (DARPA),  Navy  Labs,  Industry, 

Academia,  etc.),  development  according  to  the  agreed  upon  timeline  must  be  monitored  continuously.  Under 
DoD  Instruction  5000.2  ( hyperlink ),  a  formal  technology  readiness  assessment  must  be  conducted,  documented, 
and  reviewed  by  ONR  and  DoD  staff.  Technology  Readiness  Level  7  must  normally  be  achieved  to  proceed 
forward  with  the  implementation  of  the  new  technology  within  the  acquisition  program.  Please  see  Table  5-2. 
Appendix  A  provides  selected  references  related  to  evolving  technologies  and  their  insertion  into  ship  design. 

SEA  05T  can  also  provide  guidance  and  assistance  in  technology  development  planning  and  technology  transition 
planning.  SEA  05T  also  provides  assistance  in  conducting  Technology  Readiness  Assessments. 

Table  5-2.  Technology  Readiness  Levels 


Technology 

Readiness  Level 

Description 

1.  Basic  principles  observed  and  reported. 

Lowest  level  of  technology  readiness.  Scientific  research  begins  to  be  translated  into  technology's 
basic  properties.  Examples  might  include  paper  studies  of  a  technology's  basic  properties. 

2.  Technology  concept  and/or  application 
formulated. 

Invention  begins.  Once  basic  principles  are  observed,  practical  applications  can  be  invented.  The 
application  is  speculative  and  there  is  no  proof  or  detailed  analysis  to  support  the  assumption. 
Examples  are  still  limited  to  paper  studies. 

3.  Analytical  and  experimental  critical  function 
and/or  characteristic  proof  of  concept. 

Active  research  and  development  is  initiated.  This  includes  analytical  studies  and  laboratory  studies  to 
physically  validate  analytical  predictions  of  separate  elements  of  the  technology.  Examples 
include  components  that  are  not  yet  integrated  or  representative. 

4.  Component  and/or  breadboard  validation  in 
laboratory  environment. 

Basic  technological  components  are  integrated  to  establish  that  the  piece  will  work  together.  This  is 
relatively  Tow  fidelity”  compared  to  the  eventual  system.  Examples  include  integration  of  “ad 
hoc"  hardware  in  a  laboratory. 

5.  Component  and/or  breadboard  validation  in 
relevant  environment. 

Fidelity  of  breadboard  technology  increases  significantly.  The  basic  technological  components  are 
integrated  with  reasonably  realistic  supporting  elements  so  that  the  technology  can  be  tested  in 
simulated  environment.  Examples  include  “high  fidelity"  laboratory  integration  of  components. 

6.  System/subsystem  model  or  prototype 

demonstration  in  a  relevant  environment. 

Representative  model  or  prototype  system,  which  is  well  beyond  the  breadboard  tested  for  level  5,  is 
tested  in  a  relevant  environment.  Represents  a  major  step  up  in  a  technology’s  demonstrated 
readiness.  Examples  include  a  prototype  in  a  high  fidelity  laboratory  environment  or  in 
simulated  operational  environment. 

7.  System  prototype  demonstration  in  an 
operational  environment. 

Prototype  near  or  at  planned  operational  system.  Represents  a  major  step  up  Irom  level  6,  requiring 
the  demonstration  of  an  actual  system  prototype  in  an  operational  environment.  Examples 
include  testing  the  prototype  in  a  test  bed  aircraft. 

8.  Actual  system  completed  and  qualified  through 
test  and  demonstration. 

Technology  has  been  proven  to  work  in  its  final  lorm  and  under  expected  conditions.  In  almost  all 
cases,  this  level  represents  the  end  of  true  system  development.  Examples  include 
developmental  test  and  evaluation  of  the  system  in  its  intended  weapon  system  to  determine  il 
it  meets  specification  requirements. 

9.  Actual  system  proven  through  successful 
mission  operations. 

Actual  application  of  the  technology  in  its  final  form  and  under  mission  conditions,  such  as  those 
encountered  in  operational  test  and  evaluation.  Examples  include  using  the  system  under 
operational  mission  conditions. 
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5.1.8  In-Service  Maintenance  and  Cost  Drivers.  Visibility  and  Management  of  Operation  and  Support  Cost 
(VAMOSC)  and  TYCOM  data  should  be  reviewed  to  identify  maintenance  and  cost  drivers  for  in-service  ships. 
Improving  performance  in  these  areas  without  increasing  acquisition  costs  should  be  a  goal  of  every  design  effort. 
VAMOSC  data  is  available  at  https://vamosc.navy.mil. 

5.1.9  Single-Source  Vendor  for  Propulsion  and  Ship  Service  Electrical  Plants.  For  some  DD&C  contracts 
it  has  been  considered  beneficial  to  specify  that  the  Shipbuilder  employ  a  single-source  vendor  for  propulsion  and 
ship  service  electrical  plants.  This  approach  has  most  often  been  used  for  oceanographic  survey  ships  and 
programs  where  second  tier  shipyards  which  do  not  have  strong  in-house  design  capabilities  are  likely  to  win  the 
Detail  Design  and  Construction  contract. 

5.1.10  GFI  and  Interface  Control.  The  SDM  must  work  with  the  Program  Office  to  ensure  appropriate 
technical  review.  Errors,  PARM  changes,  and  delayed  deliveries  of  GFI,  including  interface  control  drawings, 
have  been  responsible  for  significant  disruptions  to  past  shipbuilding  programs. 

5.1.11  Units  Of  Measure.  The  Omnibus  Trade  and  Competitiveness  Act  of  1988  requires  that  all  government 
procurements  made  after  30  September  1992  use  the  metric  system  as  the  primary  system  of  measurement. 
Specific  exceptions  are  allowed  for  systems  and  equipment  that  have  already  been  developed  in  other 
measurement  systems  and  for  new  systems  where  the  use  of  metric  standards  can  be  demonstrated  to  be 
impractical.  NAVSEA  publication,  Metric  Guide  for  Naval  Ship  Systems  Design  and  Acquisition  (hyperlink), 
provides  assistance.  The  SDM  is  a  key  adviser  in  the  Program  Office  decision  on  metrication  strategy.  Recent 
programs  have  actually  done  the  design  in  metric,  but  report  out  in  “customary”  or  dual  units  to  improve 
communication  with  the  OPNAV  Sponsor  and  others  who  do  not  use  metric  units  on  a  daily  basis. 

5.1.12  Weapons  Systems  Explosive  Safety  Review  Board  Process.  All  ship  installations  of  new  or 
modified  weapons  or  weapon  systems  shall  be  formally  reviewed  and  safety  approval  received  during  the  system 
development  and  demonstration  phase.  NAVSEAINST  8020.6D  provides  guidance  on  implementation  of  a 
weapons  system  safety  program.  Weapons  and  explosives  risks  shall  be  identified  and  managed  using  the  process 
identified  in  applicable  directives  and  shall  be  briefed  to  the  Navy’s  WSESRB,  whose  charter  is  no  longer  just 
limited  to  weapons  but  to  total  ship  safety.  Therefore,  all  Navy  weapons  systems  acquisition  programs  shall  be 
reviewed  by  the  WSESRB  to  ensure  safety  requirements  are  met.  In  ships  that  are  the  first  of  a  class  or  where 
there  are  significant  variations  in  a  class,  installation  of  a  weapon  system  shall  be  formally  reviewed  and 
approved.  WSESRB  safety  identification  shall  be  obtained  before  initial  delivery  to  the  Fleet.  Programs  shall  not 
advance  to  the  next  stage  of  development  without  certification  by  the  Board.  For  new  ship  designs,  drawings  for 
review  must  detail  proposed  weapon  system  installations.  Include  locations  of  weapons  (including  cargo), 
magazines,  and  handling  space,  as  well  as  adjacent  spaces,  associated  fire  protection,  and  all  other  equipment 
related  to  weapon  system  operations. 

SDMs  of  major  combatants  should  expect  to  prepare  and  participate  in  major  technical  briefings  to  the  WSESRB 
several  times  before  the  completion  of  Contract  Design.  While  much  of  new  weapons  systems  description  will  be 
the  responsibility  of  PEO  IWS,  the  ship  Design  Team  must  present  weapons  handling,  stowage,  and  -  more 
recently  -  fire  fighting  and  other  safety  design  features.  It  is  recommended  to  start  high-level  reviews  of  the  total 
ship  to  uncover  WSESRB  issues  early  in  Preliminary  Design  when  there  is  some  definition  of  the  ship’s  major 
characteristics,  features,  and  equipments. 
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5.1.13  Complexity.  Design  complexity  is  hard  to  define,  but  its  impact  is  well  known.  It  has  been  claimed 
complexity  leads  to  fragile  designs  that  are  very  sensitive  to  small  perturbations.  It  also  complicates  design 
management  because  few  engineers  understand  the  whole  design.  This  can  lead  to  sub-optimal  design  or  different 
design  teams  working  to  cross-purposes.  Complexity  has  not  been  quantified  but  is  seen  as  a  function  of: 

•  “Number  of  ideas  you  must  hold  in  your  head  simultaneously; 

•  Duration  of  each  of  those  ideas;  and 

•  Cross  product  of  those  two  things,  times  the  severity  of  the  interactions  between  them.” 

See  Appendix  VV  ( hyperlink )  for  additional  discussion  on  complexity. 

5.1.14  Design  Maturity  Assessment.  Near  the  end  of  each  stage  of  design,  the  SDM  shall  prepare  a  Design 
Maturity  Assessment  to  demonstrate  readiness  for  proceeding  into  the  next  stage  of  design  or  production.  Tasks 
comprising  the  assessment  are  detailed  in  Appendix  WW  (hyperlink). 

5.1.15  Surface  Ship  Lessons  Learned  Feedback  Process.  SEA  05  letter  5400  Ser  05D/174  of  29  March 
2010  “NAVSEA  Surface  Ship  Lessons  Learned  Feedback  Process  Technical  Operating  Procedures”  establishes 
procedures  to  incorporate  maintenance  lessons  learned  into  the  acquisition  process. 

5.2  DESIGN  GUIDANCE.  TOOLS,  AND  RESOURCES. 

5.2.1  Industry  Best  Practices.  SDMs  are  encouraged  to  review  and  adopt,  as  applicable,  industry  best 
practices.  Sources  include  the  Best  Manufacturing  Practices  Center  of  Excellence  Website, 
http://www.bmpcoe.org,  http://www.onr.navv.mil/en/Science-Technology/Directorates/Transition/Manufacturing- 
ManT ech/C enter-Excellence/B 2PCOE. aspx ,  and  various  industry  sources. 

5.2.2  Center  for  Innovation  in  Ship  Design.  TheCISD,  managed  jointly  by  SEA  05D1  and  Carderock  Code 
20,  is  chartered  to  advance  the  theory  and  practice  of  ship  design  by  facilitating  partnerships  wherein  the  best 
ideas  and  experience  of  industry,  government,  and  academia  can  be  combined  to  explore  new  and  innovative 
ways  to  design  and  develop  naval  ships.  CISD  activities  are  focused  in  three  areas: 

•  People:  Developing  technically  skilled  ship  designers  for  the  naval  ship  design  community 

•  Knowledge:  Identifying,  learning,  and  integrating  new  technologies,  engineering  methodologies,  and 
management  tools  to  improve  the  naval  ship  design  and  development  process 

•  Innovation:  Drawing  upon  the  combined  strengths  of  ONR,  NAVSEA,  the  shipbuilding  industry,  and 
academia  in  a  collaborative,  team-learning  environment  for  innovative  whole-ship  design  studies 

SDMs  can  use  CISD  resources  along  with  program  assets  to  develop  innovative  approaches  to  ship  design  and 
then  share  “best  practices”  developed  within  their  respective  programs  with  the  community  at  large. 

SDMs  should  try  to  attend  briefings  and  review  CISD  reports  for  possible  use  in  planning.  Additionally,  they 
should  share  their  experience  in  implementing  innovative  new  approaches  to  help  capture  lessons  learned  with  the 
ship  design  community. 

The  CISD  helps  support  the  activities  of  the  Naval  Engineering  Education  Center  (NEEC)  -  a  unique  organization 
for  the  development  of  talented  engineers  necessary  to  lead  the  Navy  forward.  The  goal  is  to  provide  an 
education  experience  unparalleled  in  terms  of  student,  educator,  professional,  private,  industrial,  and  military 
cooperation.  The  NEEC  provides  young  engineers  and  scientists  access  to  projects  of  interest  and  importance 
early  in  their  academic  careers  which  builds  knowledge  and  enthusiasm  for  the  field.  The  NEEC  is  composed  of 
the  Navy,  The  American  Society  of  Naval  Engineers,  The  Society  of  Naval  Architects  &  Marine  Engineers,  and 
15  institutions  of  higher  education  all  of  which  are  based  in  the  U.S.  See  http://www.neecportal.org. 
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5.2.3  Design  Standards.  A  number  of  ship  design  standards  were  generally  recognized  as  effective  in  ensuring 
ship  performance.  In  the  past,  these  were  developed  and  formally  issued  under  the  provisions  of 
NAVSEAINST  9070.6  that  has  since  been  cancelled.  Design  standards  have  been  largely  incorporated  into  ABS 
and  other  commercial  standards. 

5.2.4  Design  Data  Sheets.  A  number  of  ship  design  data  sheets  have  become  generally  recognized  as 
effective  in  ensuring  ship  performance  in  areas  such  as  seakeeping,  survivability,  powering,  and  endurance. 

Design  data  sheets  still  recognized,  and  that  should  be  considered  for  use  in  ship  design,  are  available  from 
SEA  05S. 

5.2.5  Design  Tools  including  Product  Model.  The  SDM  must  be  careful  in  their  selection  to  ensure 
compatibility  and  the  utility  of  the  design  products  for  subsequent  phases.  SDMs  and  SIMs  shall  perform  one  or 
more  tools  readiness  reviews  to  ensure  the  design  process  and  certification  can  be  executed  to  plan.  Accessing 
availability  of  tools  is  not  sufficient;  assessing  the  validation  and  verification  of  the  tools  is  also  required.  The 
tools  readiness  reviews  should  be  scheduled  to  provide  sufficient  time  to  address  shortfalls  in  the  toolset  before 
the  tools  are  needed  to  support  the  design. 

The  SDM  needs  to  plan  how  he  will  leverage  use  of  the  shipbuilder’s  product  model  to  monitor  the  progress  of 
their  design  efforts. 

5.2.6  Use  of  Point  Designs.  Developing  and  maintaining  an  in-house  Navy  “point”  or  “reference”  design 
throughout  the  design  phases  where  industry  has  the  lead  is  a  good  risk  mitigation  technique.  A  reference  design 
is  useful  in  demonstrating  that  the  design  requirements  as  expressed  by  the  Functional  and  Allocated  Baselines 
are  technically  feasible  and  the  described  ship  can  be  acquired  within  the  existing  budget.  Reference  designs  are 
also  useful  for  identifying  technical  risks  that  should  be  mitigated  as  early  as  possible.  Finally,  they  can  be 
compared  to  contractor  proposed  designs  to  identify  differences  and  potentially  identify  weaknesses  and  strengths 
in  it.  Experience  since  the  1980s  has  shown  that  unless  the  government  develops  a  reference  design,  adequately 
assessing  industry  designs  for  feasibility  and  reasonableness  is  very  difficult. 

The  point  design  can  be  used  to: 

•  Validate  the  effects  of  mission  requirements  at  the  total  ship  level  and  identify  those  requirements  that 
drive  ship  size  and  cost 

•  Identify  areas  of  ship  design  complexity  and  technical  risk 

•  Quantify  the  whole-ship  impact  of  new  technologies 

•  Establish  a  technical  baseline  against  which  to  assess  proposed  industry  concepts  and  major  system  and 
subsystem  trade-offs 

•  Establish  a  basis  for  shipboard  manning  estimates 

•  Establish  a  basis  for  Class  F  estimates  of  ship  construction  cost  and  estimates  of  annual  operating  and 
support  costs 

•  Characterize  the  design’s  key  performance  and  other  features  to  enable  early  assessments  of  mission 
effectiveness  by  the  government 
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5.3  DESIGN  ANALYSIS  AND  VALIDATION. 

5.3.1  Operations  Analysis.  Operations  analysis  is  the  process  of  using  the  results  of  modeling  and  simulation 
and  other  studies  and  research  to  develop  alternative  solutions.  The  SDM  should  engage  with  the  Program  Office, 
OPNAV  Sponsor,  Center  for  Naval  Analyses,  and  others  in  framing  the  early  studies. 

5.3.2  Modeling  and  Simulation.  Modeling  and  simulation  is  playing  an  increasing  role  in  design  and  testing. 
Verification,  Validation  and  Accreditation  (VV&A)  must  be  accomplished  for  results  to  be  accepted.  The  SDM 
should  take  the  lead  in  planning  all  modeling  and  simulation.  Appendix  A  provides  selected  references  related  to 
modeling  and  simulation. 

5.3.3  Hydrodynamic  Model  Testing.  Model  tests  for  surface  ships  are  carried  out  to  confirm  hydrodynamic 
performance  predictions  or  to  determine  characteristics  that  cannot  be  accurately  assessed  through  analytic  means. 
To  the  extent  desired  by  the  overall  systems  engineering  approach,  hull  form  characteristics  may  be  optimized 
using  model  tests  or  a  combination  of  model  tests  and  computational  fluid  dynamics.  Model  tests  are  typically 
carried  out  during  the  later  part  of  Preliminary  Design  and  during  Contract  Design.  Some  examples  of  model  test 
objectives  are  provided  in  Table  5-3. 
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Table  5-3.  Hydrodynamic  Model  Testing 


Resistance  and 
Propulsion  Tests 

•  Determining  resistance  and  propulsion  characteristics.  It  may  be  important  to  improve  the 
accuracy  of  the  prediction  beyond  that  estimated  using  predictive  standard  series  techniques. 

For  some  ships,  the  hull  form  parameters  may  be  outside  of  the  range  of  available  data  and 
model  tests  may  be  particularly  important.  Appendage  details  may  require  investigation. 

•  Determining  the  impact  of  changes,  comparing  alternative  hull  forms,  or  optimizing  the  hull  for  a 
particular  purpose.  Selecting  final  bulbous  bow  characteristics  to  suit  various  operating 
conditions  may  require  comparative  tests. 

•  Improving  the  level  of  confidence  in  a  powering  prediction.  This  could  be  desirable  for  many 
reasons,  including  the  selection  of  a  specific  diesel  engine  or  gas  turbine. 

Propulsor  Tests 

•  Evaluating  wake  characteristics  of  the  hull  to  assist  in  propeller  design  and  optimization. 

•  Evaluating  alternative  propulsors  or  improving  the  accuracy  of  propulsor  efficiency  predictions. 

•  Determining  propulsor  cavitation  or  noise  characteristics.  For  some  ships  where  these 
characteristics  are  KPPs,  such  tests  may  be  essential  to  confirming  such  performance. 

Maneuvering  Tests 

•  Determining  the  maneuvering  characteristics.  This  may  be  particularly  important  for  hull  forms 
that  have  unusual  proportions  for  which  prediction  techniques  are  not  accurate.  Also,  ships 
that  conduct  alongside  operations  such  as  underway  replenishment  maneuver  in  very  confined 
areas  or  have  particularly  demanding  maneuvering  requirements.  They  may  require  tests 
where  predictions  are  not  accurate  or  a  higher  degree  of  accuracy  is  required. 

•  Evaluating  alternative  control  surfaces  relative  to  maneuvering  requirements. 

Ship  Motions  Tests 

•  Predicting  accelerations,  periods,  and  magnitudes  of  motions.  Unusual  hull  forms  or 
characteristics  may  require  tests  to  accurately  determine  the  range  of  accelerations.  This  could 
be  to  assess  operating  limits,  to  provide  structural  or  system  design  information,  or  to  support 

HSI  objectives. 

•  Predicting  slamming  characteristics. 

Special 

Hydrodynamic  Tests 

•  Determining  astern  powering  or  stopping  characteristics. 

•  Flow  visualization.  This  may  be  needed  to  align  appendages,  or  for  special  mission  ships,  to 
assist  in  minimizing  hydrodynamic  noise. 

•  Fin  stabilizer  alignment. 

•  Determination  of  propeller-induced  vibratory  forces. 

•  Shaft  and  strut  alignment. 

•  Topside  airflow. 

•  Dynamic  Stability.  The  increasing  interest  in  dynamic  stability  and  unusual  hull  forms  may 
require  tests  to  assess  stability  characteristics  in  special  conditions. 

•  Examining  special  hydrodynamic  phenomena.  An  example  of  this  might  be  the  behavior  of 
water  within  a  well  under  specific  conditions. 

•  Determining  structural  loads.  These  may  be  required  for  structural  design  purposes  or  to 
investigate  operating  constraints. 
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Early  in  the  design  process,  hydrodynamic  characteristics  are  estimated  using  various  predictive  techniques  or 
judgments.  Depending  on  mission  requirements,  the  sensitivity  of  the  design  to  the  predictions  will  vary.  Where 
the  result  of  the  prediction  has  a  significant  effect  on  the  overall  design,  increasingly  refined  predictions  are 
required.  As  Preliminary  Design  continues,  the  characteristics  of  the  ship  become  more  firm,  more  aspects  of  the 
ship  are  defined,  and  changes  are  more  difficult  to  incorporate.  For  these  reasons,  model  testing  is  frequently 
conducted  during  the  later  stages  of  Preliminary  Design  so  that  there  is  high  confidence  in  the  predictions  at  the 
stai't  of  Contract  Design.  The  SDM  must  assess  the  potential  influence  of  aspects  of  the  design  and  determine  if 
model  tests  are  needed  to  improve  estimates. 

The  more  critical  a  requirement  is  that  model  tests  more  likely  will  be  required  to  validate  that  the  requirement 
can  be  met.  Hydrodynamic  tests  also  provide  a  reference  for  full-scale  dials  that  provide  the  final  confirmation 
that  a  ship  meets  certain  requirements. 

Since  model  tests  cannot  be  performed  instantly,  the  SDM  must  allow  sufficient  time  to  accomplish  them.  This 
requires  that  the  configuration  to  be  tested  is  defined,  that  test  facilities  can  be  selected,  that  the  schedule  permits 
the  tests  to  be  accomplished,  that  contractual  documentation  and  tasking  be  completed,  and  that  results  can  be 
produced  in  a  timely  manner.  The  TWH  for  hydrodynamics  will  provide  expertise  in  planning  such  tests, 
selecting  facilities  based  on  the  tests  desired,  arranging  for  and  overseeing  such  tests,  and  evaluating  and 
documenting  the  results. 

5.3.4  Test  and  Evaluation.  “Testers”  generally  divide  their  efforts  into  developmental  testing,  operational 
testing,  and  LFT&E.  All  three  categories  of  test  come  into  play  during  the  course  of  a  typical  ship  acquisition 
program.  It  is  not  unusual  for  all  three  categories  to  be  supported  by  some  type  of  planning  or  development  effort 
by  the  ship  Design  Team. 

While  these  three  types  of  tests  are  separate  and  serve  different  puiposes  (and  sometimes  different  customers), 
they  are  interrelated  and  should  be  closely  coordinated.  The  SDM/SIM  and  the  Program  Office  should  have  a 
single  point  of  contact  for  all  test  matters,  and  must  have  a  clear  understanding  of  the  overall  test  effort,  the 
interrelationships  of  the  various  test  programs,  and  the  division  of  authority  between  them. 

It  is  important  that  all  requirements  identified  in  the  CDD  and  CPD  be  testable.  COMOPTEVFOR  will  pursue 
operational  testing  for  each.  These  requirements  should  flow  down  to  the  Specifications  that  should,  in  turn,  flow 
down  to  Specification  testing  requirements  and  test  planning  documentation.  Demonstration  of  performance  is 
critical  when  Specifications  are  defined  in  performance  terms. 

Since  T&E  programs  are  reviewed  by  DoD  at  each  Milestone,  they  have  a  greater  influence  on  the  design  effort 
than  might  be  expected.  Significant  SDM/SIM  resources  may  be  needed  to  develop  and  monitor  tests.  For 
example,  FFT&E  is  usually  done  early  in  a  program  so  it  can  influence  the  design.  It  may  require  modifying  and 
blowing  up  or  burning  decommissioned  ships  and  may  be  expensive,  time  consuming,  dangerous,  and  force 
significant  design  changes  downstream.  Also,  a  working-level  IPT  is  often  formed  from  DoD,  OPNAV, 
COMOPTEVFOR,  and  Program  Office  personnel  to  regularly  review  the  progress  of  tests  and  test  planning. 
Much  of  the  subject  matter  of  this  group  consists  of  the  technical  issues  of  design,  requirements,  and  tests  -  all 
SDM/SIM -cognizant  areas. 

The  governing  document  is  the  Test  and  Evaluation  Strategy  (TES)  and  subsequent  Test  and  Evaluation  Master 
Plan  (TEMP),  which  outline  the  total  testing  approach  for  the  entire  program.  The  TEMP  specifies  critical 
technical  parameters  against  which  the  design  will  be  measured.  It  also  contains  funding  requirements  for  testing 
which  are  often  in  competition  with  the  SDM’s  other  funding  needs.  Within  a  Program  Office,  T&E 
responsibility  is  often  given  to  someone  outside  the  SDM  organization.  However,  close  attention  must  be  paid  to 
this  document  and  engineering  resources  must  be  diverted  from  regular  design  work  to  avoid  losing  control  of  the 
T&E  process  to  outside  entities.  It  has  been  said  that  the  Director,  Operational  Test  and  Evaluation  (DOT&E)  is 
one  of  the  few  organizations  that  can  stop  a  Program.  It  hasn’t  happened  to  a  Navy  ship  program  -  yet. 
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Other  test  and  evaluation  documentation  that  will  need  to  be  developed  includes  an  LFT&E  management  plan, 
modeling  and  simulation  plan,  and  VV&A  Plan. 

Early  involvement  by  COMOPTEVFOR  in  development  of  the  CDD  is  useful  to  ensure  requirements  are  testable. 
Appendix  A  provides  selected  references  related  to  test  and  evaluation. 

5.3.5  INSLJRV.  The  SDM  should  review  Board  of  Inspection  and  Survey  (INSURV)  results  of  similar  classes 
for  possible  consideration  in  the  design.  INSURV  may  be  requested  to  review  and  recommend  improvements  for 
new  ship  designs.  This  is  normally  accomplished  prior  to  the  end  of  Preliminary  Design  and  Contract  Design. 

5.3.6  Real  Options.  There  is  a  large  and  growing  literature  on  “real”  options,  that  is,  on  the  application  (or 
potential  application)  of  financial  options  analysis  methods  to  the  evaluation  of  certain  kinds  of  non-financial 
investments  such  as  large  engineering  projects.  It  is  generally  accepted  that  an  options  perspective  (1)  “leads 
analysts  to  adopt  a  substantially  different  perspective  on  how  to  design  systems  for  uncertainty,”  (2)  will  tilt 
investments  toward  “broad  classes  of  projects  that  are  much  more  valuable  than  they  have  appeared  to  be,”  and 
(3)  will  encourage  information-gathering  “on  the  ways  uncertainties  resolve,  so  that  the  system  managers  can 
exploit  the  value  in  the  options”  (de  Neufville,  Richard.  2003.  “Real  options:  Dealing  with  uncertainty  in  systems 
planning  and  design.”  Integrated  Assessment,  vol.  4,  no.  1,  26-34.). 

The  options-based  approach  is  a  supplement  to  existing  processes  for  valuing  alternative  capital  investment 
projects.  With  further  development,  options-based  analysis  could  offer  a  way  to  document  a  component  of 
project  value  which  has,  so  far,  been  implicitly,  tacitly,  or  indirectly  perceived. 

Explicit  recognition  and  documentation  of  option  value  is  likely  to  have  three  kinds  of  effects: 

•  In  the  design  stage,  options  analysis  enables  more  realistic  assessments  of  technologies  and  design 
features  that  add  flexibility  during  development  and  adaptability  during  the  post-commissioning  life 
cycle.  Under  conventional  engineering  economics  approaches,  these  are  undervalued. 

•  During  the  project  management  stage,  options  analysis  focuses  more  attention  on  uncertainty,  because 
the  implications  and  opportunities  created  by  uncertainty  are  more  completely  defined.  The  value  of 
project  modifications  and  adaptation  as  future  information  comes  to  light  and  uncertainty  is  resolved, 
are  more  clearly  highlighted. 

•  Finally,  options  analysis  adds  a  new  perspective  on  project  risk,  as  option  value  increases  with  the  level 
of  volatility  and  uncertainty  in  the  final  project  outcome. 

What  are  the  “broad  classes  of  projects”  whose  true  worth,  currently  undervalued,  will  be  more  accurately 
revealed  using  options  analysis?  In  terms  of  naval  ship  design  and  planning,  the  most  obvious  are  R&D,  early 
stage  design,  and  the  development  of  modularity  design  features.  These  are  notoriously  difficult  to  value. 

The  above  text  is  taken  from  Dr.  Phil  Koenig,  “Real  options  in  ship  and  force  structure  analysis:  A  research 
agenda,”  presented  at  ASNE  Day  2009.  For  further  information  on  applying  Real  Options,  please  refer  to  this 
paper.  Note  that  there  is  concern  by  some  that  this  is  based  on  industry  and  financial  experience  and  application 
of  this  to  government  programs  needs  work  and  investigation. 
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5.3.7  Requirements  Risk  (Market  Risk).  Typically  Risk  Analysis  is  used  to  control  Schedule,  Cost,  and 
Performance  Risk.  Requirements  Risk  Analysis  should  also  be  performed  to  anticipate  and  mitigate  the  cost  of 
changes  in  customer  or  derived  requirements.  Requirements  Risk  is  an  analog  of  “Market  Risk”  in  the 
commercial  sector  which  tries  to  measure  the  risk  of  the  developed  product  not  meeting  customer  expectations 
and  failing  in  the  market  place.  Requirements  Risk  Analysis  is  a  means  for  applying  well  known  risk 
management  techniques  to  identify  requirements  that  are  likely  to  change  over  the  service  life  of  the  ship  and  to 
develop  mitigation  plans  for  dealing  with  these  changing  requirements. 

Typically  an  engineer  desires  to  develop  systems  that  meet  a  specific  set  of  requirements.  In  reality,  the 
requirements  are  not  always  that  firm  and  change  over  time.  To  date,  the  approaches  for  dealing  with  uncertainty 
in  requirements  has  been  ad  hoc  such  as  using  margins  and  service  life  allowances  based  on  past  performance 
problems  and  indiscriminately  mandating  open  systems  architectures  or  modularity  (whether  or  not  they  are 
warranted).  This  had  led  to  many  missed  opportunities  for  building  flexibility  into  the  design  where  they  can 
have  significant  payoff. 

The  requirements  analysis  block  of  the  systems  engineering  process  should  incorporate  a  requirements  risk 
analysis.  In  this  manner,  the  functional  allocation  block  can  help  mitigate  high-risk  requirements  by  partitioning 
them  into  their  own  configuration  items,  ideally  as  part  of  an  open-systems  architecture.  A  good  architecture  will 
have  rigidity  in  those  areas  where  requirements  are  not  likely  to  change,  and  provide  substantial  flexibility  in 
those  areas  where  requirements  are  likely  to  change.  Modularity  and  carefully  crafted  margins  and  service  life 
allowances  become  effective  tools  for  enabling  a  design  to  adapt  to  future  changes  in  requirements.  In  this 
manner,  Requirements  Risk  Analysis  becomes  an  integral  part  of  the  systems  engineering  process  and  should 
result  in  robust  systems  capable  of  quickly  adapting  to  changing  requirements. 

5.4  ADDITIONAL  DESIGN  CONSIDERATIONS. 

5.4.1  Modular  Design.  Many  of  our  ships,  particularly  surface  combatants,  have  in  the  past  failed  to  achieve 
their  design  service  life.  In  many  cases  this  was  due  to  the  inability  to  affordably  upgrade  the  combat  systems  to 
ensure  continued  military  relevance.  Where  appropriate,  Modular  Adaptable  Ship  (MAS)  technologies  can 
improve  affordability  in  addition  to  improving  the  military  relevance  of  warships  to  their  service  life.  MAS 
technologies  include,  but  are  not  limited  to,  modular  hull  ships,  mission  bays,  container  stacks,  weapon 
modules/zones,  aperture  stations,  electronic  module  enclosures,  and  flexible  infrastructure.  For  more  information 
see:  “A  Guide  for  Design  of  Modular  Zones  on  US  Navy  Surface  Combatants,”  SEA  05T  ser  05T/04  of  January 
2011  and  “Modular  Adaptable  Ship  (MAS)  Total  Ship  Design  Guide  for  Surface  Combatants,”  05T  Ser  05T/09  of 
February  201 1  (hyperlink). 

5.4.2  Topside  Design.  Navy  surface  ships  provide  a  significant  challenge  for  locating  components  on  their 
topsides.  These  ships  typically  have  limited  topside  space  and,  in  the  case  of  many  new  designs,  all  topside 
equipment  must  meet  rigid  signature  control  requirements.  Naval  topside  design  for  surface  ships  is,  by  necessity, 
a  search  to  find  innovative  ways  to  meet  competing  requirements  for  system  functionality  within  space,  weight, 
and  cost  constraints.  The  topside  must  accommodate  a  wide  array  of  combat,  C4I,  anti-terrorism  and  force 
protection,  and  hull,  mechanical,  and  electrical  functions  while  maintaining  maximum  functionality  of  all  systems 
to  do  their  individual  jobs.  The  topside  must  also  serve  the  basic  ship  operational  functions  such  as  UNREP, 
flight  operations,  small  boat  deployment,  docking  and  maneuvering,  navigation,  and  safety  of  personnel 
movement.  All  of  this  must  be  done  while  meeting  overall  ship  signature  requirements  and  imposing  minimal 
manning  and  operating  effects.  Please  see  Figure  5-8  and  NAVSEA  05  Memorandum  9830  Ser  05D/312  of  1 1 
October  2007  “Integrated  Topside  Design  and  Certification  Process  for  New  Construction  Ships”  (hyperlink). 
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Figure  5-8.  Topside  Incorporates  Many  Disciplines 

5.4.3  Survivability  and  Force  Protection.  Survivability  addresses  susceptibility,  vulnerability,  and 
recoverability.  It  should  be  considered  a  fundamental  design  requirement  of  no  less  significance  than  other 
inherent  ship  characteristics,  such  as  weight  and  stability  margins,  maneuverability,  structural  integrity,  and 
combat  systems  capability.  Survivability  is  now  also  a  mandatory  KPP.  It  should  be  discussed  in  terms  of  the 
expected  exposure  of  the  ship  to  threat  weapons  (available  from  the  System  Threat  Assessment  Report  (STAR)) 
within  the  projected  operating  environment,  as  well  as  the  expected  performance  of  the  ship  after  suffering 
weapons  induced  damage.  Is  the  ship  expected  to  remain  afloat?  Is  it  expected  to  be  able  to  restore  mission 
capability  quickly?  Is  it  expected  to  maintain  mission  capability,  even  though  damaged?  The  performance  of  the 
ship  within  the  projected  environment  can  be  evaluated  through  a  total  ship  survivability  analysis.  Such  planning 
should  begin  early  to  ensure  the  availability  of  sufficient  resources.  It  should  also  ensure  survivability 
performance  can  be  considered  as  part  of  the  AoA  and  in  deciding  the  operational  requirements  for  the  ship. 
Appendix  A  provides  guidance  related  to  survivability. 

Force  protection  is  another  new  mandatory  KPP.  It  addresses  protection  for  embarked  personnel  against  tertiary 
threats  including  preemptive  attacks  or  covert  action  from  special  operations  forces,  combat  divers,  and  terrorists. 
Integrated  designs  of  weapons,  sensors,  and  associated  support  have  been  developed  for  installation  onboard  new 
and  existing  ships. 

5.4.4  Energy  Efficiency.  Per  USD  AT&L  Memo  of  14  September  2010,  Implementation  Directive  for  Better 
Buying  Power  -  Restoring  Affordability  and  Productivity  in  Defense  Spending  ( hyperlink ),  and  ASN(RDA) 
Memo  of  20  June  2011,  Energy  Evaluation  Factors  in  the  Acquisition  Process  (hyperlink),  energy  efficiency  is 
now  required  to  be  considered  during  the  AoA  and  addressed  in  requirements  definition  and  budgeting. 
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5.4.5  Reliability.  Availability,  and  Maintainability.  Reliability,  Availability  and  Maintainability  (RAM)  is  a 
significant  design  factor  and  RAM  requirements  definition  and  analysis  should  be  managed  by  the  SDM,  not  the 
Program  Office  Logistics  Division.  Materiel  availability  is  now  a  required  KPP  and  materiel  reliability  a  required 
KSA  for  the  CDD  and  CPD.  RAM  must  be  considered  during  the  AoA  and  a  RAM-C  Report  is  a  required 
attachment  to  the  AoA  Report.  The  SDM  must  be  careful  to  ensure  that  the  criteria  and  assumptions  for  the 
analysis  are  carefully  defined,  fully  vetted,  and  documented.  In  particular,  failure  data  on  commercial  equipment 
is  very  difficult,  if  not  impossible,  to  obtain. 

For  RAM  to  be  useful,  the  definitions  of  what  constitute  a  failure,  as  well  as  the  definition  of  “time,”  must  be 
carefully  made.  In  particular,  failures  should  be  defined  in  terms  of  the  ability  to  perform  primary  and  secondary 
missions.  In  any  case,  the  RAM  analysis  should  influence  the  selection  of  hardware,  software,  redundancy,  and 
system  architecture.  It  should  be  considered  to  be  closely  associated  to  HSI  in  that  a  major  contributor  to  system 
reliability  is  human  reliability,  and  that  the  maintainability  of  shipboard  systems  has  a  major  effect  on  personnel 
workload  and  skill  requirements.  SDMs  need  to  develop  a  design  reference  mission  as  the  basis  for  assessing 
RAM  adequacy  against  a  postulated  set  of  ship  functions.  Contract  requirements  need  to  support  Shipbuilder 
consideration  of  RAM  for  DD&C.  See  the  RAM-C  Guidebook  (hyperlink'). 

5.4.6  Environmental,  Safety  and  Occupational  Health  Compliance.  Preparation  of  applicable  National 
Environmental  Policy  Act  and  Executive  Order  12114  documentation  is  considered  an  integral  part  of  planning 
for  testing,  production,  and  deployment.  Environmental  planning  process  should  be  initiated  at  the  outset  of  new 
program  planning  and  incorporated  into  the  subsequent  design  and  acquisition. 

Hazardous  material  is  defined  as  anything  that,  because  of  its  quantity,  concentration,  or  chemical,  biological,  or 
physical  characteristics,  may  pose  substantial  hazard  to  human  health  or  the  environment  and  generate 
environmental,  safety,  and  occupational  health  related  concerns  that  require  an  elevated  level  of  effort  to  manage. 
This  definition  includes  materials  that  may  be  used  in  manufacturing,  operations,  maintenance,  and  disposal  over 
a  system’s  life  cycle  that  may  result  in  the  release  of  hazardous  materials.  Specifications  must  contain  provisions 
to  strictly  limit  their  use. 

The  SDM  should  consider  pollution  prevention  methods,  practices,  and  technologies  early  in  the  program  to 
mitigate  their  cost,  and  schedule  risks.  Pollution  prevention  should  be  an  integral  part  of  systems  engineering 
throughout  the  life  cycle  of  the  program.  Total  ship,  systems,  and  equipment-level  disposals  should  be  planned. 

A  formal  system  safety  program  will  also  need  to  be  implemented  by  the  Program  and  the  Shipbuilder. 

The  references  listed  in  Appendix  A  provide  guidance  on  ESOH  compliance. 
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5.4.7  NAVSEA  Critical  Safety  Item  Program.  The  NAVSEA  Critical  Safety  Item  (CSI)  Program  was  created 
to  combat  a  trend  of  nonconforming  material  issues  in  critical  safety  parts.  Section  130  of  the  John  Warner 
National  Defense  Authorization  Act  for  Fiscal  Year  2007  re-established  technical  authority  over  procurement  of 
ship  CSIs  lost  under  the  Federal  Acquisition  Reform  Act  of  1996.  NAVSEAINST  9078.1  details  NAVSEA 
policy,  responsibilities,  coordination,  and  awareness  in  the  procurement,  modification,  repair,  and  refurbishment 
of  ship  non-nuclear  CSIs.  NAVSEAINST  9078.2  details  the  technical  requirements  and  procedures  for 
implementing  the  ship  CSI  program. 

CSI  is  defined  as  “Any  ship  part,  assembly,  or  support  equipment  containing  a  critical  characteristic  whose 
failure,  malfunction,  or  absence  may  cause  a  catastrophic  or  critical  failure  resulting  in  loss  or  serious  damage  to 
the  ship,  or  unacceptable  risk  of  personal  injury  or  loss  of  life.”  Since  this  definition  is  rather  broad,  the  LHA  7 
program  is  currently  piloting  a  CSI  review  of  the  LHS  7  in  an  effort  to  refine  the  definition. 

Per  NAVSEAINST  9078.2  (hyperlink'),  SDMs  shall  participate  in  the  CSI  determination  process  for 
modernization,  overhaul,  and  new  construction  programs.  SDMs  review  the  CSI  definition,  any  established  CSI 
determination  criteria,  and  consult  with  the  component/system  as  necessary  to  determine  when  an  item  should  be 
a  CSI.  Concurrence  with  any  new  CSI  determination  criteria  is  obtained  from  the  component/system  TWH. 

For  new  construction  designs  where  a  Design  Agent  (DA)  is  performing  the  Design,  the  DA  shall  conduct  the  CSI 
and  critical  characteristic  review  and  forward  to  the  SDM  team  via  DRL  for  review.  For  in-house  designs,  the 
SDM  leads  the  review.  An  overview  of  the  review  process  is  outlined  below. 

•  The  systems  for  the  ship  shall  be  identified 

•  Interfacing  systems  shall  be  identified 

•  For  each  system  identify 

-  System  function 

-  Interfacing  function  with  other  systems 

-  System  failure  modes 

•  Question  each  system  to  determine  if  system  failure  would  result  in: 

-  Loss  of,  or  serious  damage  to  the  ship  or 

-  Unacceptable  risk  of  personal  injury  or 

-  Loss  of  life 

•  For  systems  identified  with  potential  CSI,  forward  SDM  analysis  to  component/system  TWH  for  CSI 
determination 

In  the  process  of  identifying  CSI,  the  following  can  be  assumed: 

•  Determining  factor  is  consequence  of  failure,  NOT  probability 

•  Shock  loading  and  loss  of  mission  capability  are  not  considered 

•  Assume  equipment  is  being  operated  in  accordance  with  approved  operating  and  casualty  procedures 

•  Assume  single  failure  occurs  in  the  locations  that  would  result  in  the  greatest  consequence  to  the  ship 

•  If  strength  is  degraded  due  to  a  single  failure,  determine  if  progressive  failure  occurs 

•  Evaluate  consequence  of  failure  under  the  most  severe  condition  at  which  the  item  is  designed  to 
operate 

The  final  determination  for  declaring  equipment  to  be  CSI  is  made  by  the  applicable  DWO. 
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5.4.8  Human  Systems  Integration.  HSI  addresses  the  human  component  (operators,  maintainers,  and  decision 
makers)  of  the  total  system  design.  Just  as  integration  and  information  exchange  requirements  must  be  defined 
for  hardware  and  software  interfaces,  operator  and  maintainer  interfaces  with  hardware  and  software  and  with  one 
another  must  be  explicitly  defined  and  optimized  to  support  overall  system  performance  requirements.  HSI 
provides  the  methods  and  discipline  to  ensure  effective  and  efficient  utilization  of  human  resources  within  the 
total  system  design. 

HSI  is  composed  of  the  systems  engineering  process  and  program  management  efforts  that  provide  integrated  and 
comprehensive  analysis,  design,  and  assessment  of  requirements,  concepts,  and  resources  for: 

•  Manpower 

•  Personnel 

•  Training 

•  HFE 

•  Safety 

•  Occupational  Health 

•  Personnel  Survivability 

•  Habitability 

Under  SECNAVINST  5000.2  ( hyperlink ),  the  Navy  requires  its  Program  Managers  and  Sponsors  to  initiate  an 
HSI  effort  as  early  in  the  acquisition  process  as  possible  and  address  HSI  throughout  all  phases  of  the  acquisition 
process  to  optimize  total  system  performance,  minimize  total  ownership  costs,  and  ensure  that  the  system  is  built 
to  accommodate  the  characteristics  of  the  user  population  that  will  operate,  maintain,  and  support  the  system. 
Human  factors  engineering  and  safety  reviews  should  be  incorporated  into  the  Preliminary,  Contract,  and  Detail 
Design  process. 

Note  that  the  Technical  Authority  for  HSI  flows  from  the  Deputy  Warranting  Officer  to  the  SDM.  It  is  up  to  the 
SDM  to  ensure  there  is  an  HSI  SME  on  the  design  team. 

See  Section  3.2  and  Appendix  QQ  ( hyperlink )  for  additional  discussions. 

5.4.9  NAVSEA  Commonality  Program  and  standardization.  The  Commonality  Program  reduces  the  variety 
of  systems,  subsystems,  and  components  used  in  ship  systems  installed  in  the  Fleet,  fosters  cross-platform 
commonality  and  reduces  total  ownership  costs.  Commonality  through  reduction  in  variation  based  on 
requirements,  total  ownership  cost,  and  quality  supports  a  reduction  in  new  acquisition,  and  modernization  costs 
while  supporting  a  reduction  in  new  acquisition,  modernization  and  upgrade  program  risk  in  component  selection, 
acquisition  and  life  cycle  costs  and  parts  within  the  Navy  logistics  system.  NAVSEAINST  4120.8  ( hyperlink ) 
establishes  requirements  to  develop,  manage,  and  communicate  standard  engineering  specifications  and  parts  lists 
to  reduce  program  risk  and  cost  by  implementing  a  Virtual  Shelf  commonality  concept. 

The  Virtual  Shelf  is  an  online  repository  of  information  for  programs  to  use  in  designing  ship  systems  during 
acquisitions  and  modernizations.  The  Shelf  systems  and  components  are  aligned  by  SWBS.  The  Shelf  can 
contain  detailed  system  or  component  specifications,  system  architectures  and  components  with  related 
Allowance  Parts  List/Navy  Item  Identification  Number  information.  The  Shelf,  if  appropriate,  will  identify  those 
components  which  have  Commodity  Contracts.  Commodity  Contracts  will  be  available  to  the  shipyards  to  use 
and  procure  shelf  items  via  the  Naval  Inventory  Control  Point  contracts. 
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The  “Shelf’  will  contain  standard  engineering  specifications  including: 

•  Engineering  descriptions  of  shelf  items  to  enable  integration  of  shelf  items  into  standard  architectures 

•  Specifications  for  shelf  items  to  facilitate  procurement  of  shelf  items 

•  A  shelf  selection  tool  to  support  the  user  in  selecting  shelf  items  based  on  the  components’  design 
requirements 

•  Total  Ownership  Cost  Data  and  Business  Case  Analysis  templates  to  support  developing  the  Business 
Case  Analysis 

•  A  Shelf  Roadmap  indicating  the  expected  lifespan  of  each  element  on  the  shelf 
These  items  are  collectively  referred  to  as  Shelf  Items  in  the  context  of  the  Commonality  Program. 

SDMs  have  responsibilities  under  the  Commonality  Program  to: 

•  Assist  SIMs  &  TWHs  in  establishing  and  managing  the  engineering  standards  included  in  the  Shelf 

•  Develop  ship  systems  designs  with  use  of  Shelf  items  as  described  in  the  Commonality  Handbook 

•  Facilitate  contractors  use  of  Shelf  items  in  the  design  of  ship  systems 

•  Ensure  that  Shelf  requirements  are  included  in  technical  data  packages 

Details  of  the  Commonality  Program  are  outlined  in  the  Commonality  Handbook  for  Program  Managers  and  Ship 
Design  Managers  (hyperlink). 

Standardization  of  parts  and  equipment  within  the  individual  ship,  ship  class,  and  the  Fleet  is  desirable  and  is 
sometimes  incentivized  by  the  contract.  Standardization  goes  beyond  the  implementation  of  Commonality  as 
described  above.  Standardization  includes  minimizing  the  total  number  of  different  types  of  parts  used  in  the  ship 
design. 

Standardization  can  also  take  the  form  of  “class  standard  equipment”  which  may  be  procured  or  managed 
separately  from  the  ship  construction  contracts.  This  was  accomplished  for  SEALIFT  programs.  SDMs  may  be 
asked  to  manage  separate  design  packages,  source  selections,  etc.  in  support  of  such  efforts.  Appendix  A 
provides  selected  references  related  to  standardization. 

5.4. 1 0  Interoperability  and  Net  Readiness.  Net  readiness,  including  interoperability,  is  a  mandatory  KPP 
under  the  provisions  of  CJCSI  6212.01  (hyperlink).  Development  of  related  architectures  must  begin  to  support 
development  of  the  ICD  and  continue  for  the  CDD  and  Information  Support  Plan  (ISP).  The  SDM  should  ensure 
the  C4ISR  SEM  begins  to  address  net  readiness  from  the  start  of  the  project.  Interoperability  testing  presents  a 
technical  challenge.  Appendix  A  provides  guidance  related  to  interoperability  and  net  readiness. 

5.4.11  C4ISR  and  Weapons  System  Integration.  DoN  Policy  is  to: 

•  Provide  the  C4ISR  and  Weapons  System  Suite  as  GFE  for  new  Ship  Construction,  with  PEO  C4I  and 
PEO  IWS  as  the  providers 

•  Integration  for  new  Ship  Construction  will  use  the  "Design  Budget"  process 

•  The  Government  will  establish,  use,  and  manage  a  Government  owned  ship  Network  Architecture 

•  OPNAV  N6  and  N8  will  determine  a  resourcing  construct  to  fund  C4ISR  developments,  "Design 
Budget"  process,  network  architecting,  and  supporting  engineering. 

The  SDM  must  work  closely  with  the  SIM  and  C4ISR  SEM  to  implement  these  policies. 
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The  SIM  is  technical  authority  for  warfare  systems  on  Navy  surface  ship  classes.  The  SIM  provides  technical 
oversight  to  ensure  compliance  with  policies,  instructions,  publications,  standards,  specifications,  and  other 
guidance,  performance  metrics,  tools,  and  best  practices.  The  SIM  coordinates  and  oversees  technical  reviews  of 
surface  ship  warfare  systems  requirements,  specifications,  systems  designs  and  analyses,  design  criteria,  design 
products,  and  design  waivers  in  accordance  with  the  NAVSEA  05H  and  PEO  IWS  Technical  Review  Manual. 

The  SIM  is  the  primary  point  of  contact  for  warfare  systems  integration  efforts  for  assigned  warfare  systems  and 
their  specific  ship.  The  assigned  SIM  is  responsible  for  the  review  of  system  level  artifacts  that  meet  the  warfare 
systems  requirements  and  is  safe  for  the  ship.  They  will  perform  warfare  systems  level  risk  assessments  where 
the  system  does  not  meet  the  requirement  and  recommend  solutions  to  mitigate  that  risk.  Objective  Quality 
Evidence  will  be  reviewed  for  warfare  systems  certification  panels.  SIMs  will  participate  in  Enterprise  level 
Change  Control  Board’s  (eCCB’s)  (PEOIWSINST  4130.1,  Integrated  Warfare  Systems  (IWS)  Enterprise 
Configuration  Control  Process  and  COMUSFLTFORCOMINST/COMPACFLT  4720.3  C5ISR  Modernization 
Policy)  for  configuration  control  of  the  warfare  systems  of  the  platforms.  They  will  review  artifacts  that  will 
define  interface,  weight,  distributive  system  (electrical,  cooling,  etc.),  test  requirements  for  system  installation. 
Coordination  between  the  platform  SDM(s),  SIM,  and  ship  class  Program  Offices  is  essential. 

5.4.1 2  Information  Assurance.  Information  assurance  is  a  key  performance  capability  for  the  design  of  ship 
information  technology  and  command  and  control  systems.  Under  the  Clinger-Cohen  Act,  Programs  must 
demonstrate  planning  through  development  of  an  information  assurance  strategy.  The  SDM  should  ensure  the 
C4ISR  SEM  begins  to  address  this  capability  beginning  with  CDD  development.  Appendix  A  provides  selected 
references  related  to  information  assurance. 

5.4.1 3  Open  Systems.  The  DoD  and  SECNAV  5000  series  instructions  require  programs  to  employ  an  open 
systems  approach  where  feasible.  The  best  current  source  document  is  the  Naval  Open  Architecture  Contract 
Guidebook  for  Program  Managers.  Implementation  is  normally  focused  on  systems  that  employ  information 
technology. 

5.4.14  Electromagnetic  Compatibility.  The  SDM  must  ensure  that  the  ship  will  be  electromagnetically 
compatible  within  itself  and  with  other  platforms  in  the  operating  environment.  Ships  need  to  incorporate 
measures  to  avoid  Electromagnetic  Interference  (EMI),  electromagnetic  vulnerability,  and  Radiation  Hazard 
(RADHAZ).  Ships  need  to  be  compliant  with  requirements  for  topside  design  and  electromagnetic  compatibility 
(EMC)  certification.  Emission  control  may  be  required.  SEA  05H  EMI  TWH  shall  be  involved  in  all 
Electromagnetic  design  and  review  meetings.  Appendix  A  provides  selected  references  related  to  electromagnetic 
compatibility. 

5.4.1 5  Electromagnetic  Spectrum  Certification  and  Supportabilitv.  Spectrum  certification  is  obtained  with 
approval  of  DD  Form  1494  by  CNO  (N6)  for  Navy  programs  and  Headquarters,  Marine  Corps  (HQMC)  (C4)  for 
the  Marine  Coips.  The  approved  form  is  submitted  to  the  Navy  and  Marine  Corps  Spectrum  Center  for 
coordination  with  the  Military  Communications-Electronics  Board.  Program  Offices  shall  obtain  approval  of 
DD  Form  1494  prior  to  Milestone  B  and  confirm  currency  of  the  frequency  allocation  at  each  subsequent 
milestone.  Appendix  A  provides  selected  references  related  to  electromagnetic  spectrum. 
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5.4.1 6  DoD  Architecture  Framework.  Architectures  within  the  DoD  are  created  for  a  number  of  reasons. 

From  a  compliance  perspective,  the  DoD’s  development  of  architectures  is  compelled  by  law  and  policy  (i.e., 
Clinger-Cohen  Act,  Office  of  Management  and  Budget  (OMB)  Circular  A- 130)  and  the  derivative  regulations 
such  as  CJCIS  6212.01 .  From  a  practical  perspective,  experience  has  demonstrated  that  the  management  of  large 
organizations  employing  sophisticated  systems  and  technologies  in  pursuit  of  joint  missions  demands  a  structured, 
repeatable  method  for  evaluating  investments  and  investment  alternatives,  as  well  as  the  ability  to  effectively 
implement  organizational  change,  create  new  systems,  and  deploy  new  technologies.  Towards  this  end,  the  DoD 
Architecture  Framework  (DoDAF)  was  established  as  a  guide  for  the  development  of  architectures.  See 
Appendix  RR  (hyperlink).  Note  that  for  ship  Programs  the  proven  utility  of  DoDAF  is,  so  far,  confined  to 
definition  of  the  C4I  and  weapons  system  requirements. 

5.4.17  Corrosion  Prevention.  Corrosion  prevention  is  a  significant  life  cycle  cost  reduction  measure.  At  the 
time  of  program  initiation,  the  SDM  should  identify  the  corrosion  susceptibility  of  the  prospective  system.  For  all 
programs  deemed  “corrosion  susceptible,”  the  SDM  should  establish  a  corrosion  prevention  and  control  program. 
It  should  identify  attributes  of  the  system’s  design  and  construction  that  are  likely  to  facilitate  or  exacerbate 
corrosion  during  operational  use.  The  SDM  should  adopt  environmentally  compliant  materials  selection  and 
corrosion  prevention  techniques  during  the  design  and  manufacture  of  weapon  systems.  The  SDM  may  prepare  a 
Corrosion  Prevention  and  Control  Plan  (CPCP)  and  stand  up  a  Corrosion  Prevention  Advisory  Team  (CPAT) 
early  in  the  Program.  The  Shipbuilder  will  also  be  required  to  stand  up  a  corrosion  prevention  and  control 
program. 

5.4.1 8  Material  Selection.  Material  selections  should  consider  performance,  procurement  cost,  and  total 
ownership  considerations  such  as  environmental  and  corrosion  control.  Use  of  selected  materials  is  prohibited  by 
statute  and  regulation.  Please  see  Appendix  A  for  guidance  on  the  list  of  hazardous  materials  prohibited  from  use 
in  ship  acquisition  programs. 

5.4.1 9  At  Sea  Environmental  Planning.  Efforts  are  currently  underway  to  conduct  planning  for  Navy  military 
readiness  and  scientific  research  activities  at  sea  including  the  impact  weapons  testing  and  use  of  SONAR. 

5.4.20  Underwater  Ship  Husbandry.  Requirements  for  underwater  maintenance  should  be  considered  in  the 
design. 


5-32 


S9800-AC-MAN-01 0 


CHAPTER  6 

SHIP  DESIGN  MANAGER’S  CHECKLIST 

The  following  is  a  generalized  list  of  action  items  required  of  the  SDM  in  the  preparation  of  a  new  construction 
ship  design.  This  list  should  be  studied  and  used  by  the  SDM  in  developing  a  checklist  of  action  items  to  suit  the 
peculiarities  of  his  own  ship  design.  Although  many  actions  occur  concurrently,  the  action  items  are  listed  in 
approximately  chronological  order.  An  “X”  in  the  column  for  feasibility  studies  (FS),  Pre-Preliminary  Design 
(Pre-PD),  Preliminary  Design  (PD),  Contract  Design  (CD),  or  DD&C  indicates  an  action  required  for  that  phase. 
See  Appendix  Q  for  SETR  entrance/exit  criteria  that  should  also  be  considered  in  planning. 
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ACTION 

FS 

Pre-PD 

PD 

CD 

DD&C 

Obtain  and  review  a  copy  of  the  Program  Office  tasking  and 
the  OPNAV  tasking  document  that  authorizes  the  design 
effort. 

X 

X 

X 

X 

X 

Identify  SEA  05  and  Program  Office  protocols  for  external 
communications  and  correspondence. 

X 

X 

X 

X 

X 

Conduct  turnover  with  former  SCM. 


Become  familiar  with  earlier  phase  efforts.  Obtain  copies  of 
related  earlier  phase  planning,  historical  documents  and 
products. 


Obtain  a  copy  of  any  acquisition  strategy  and  acquisition  plan 
and,  if  no  draft  is  available,  at  least  the  Program  Office’s 
Program  Objectives  and  Milestones. 


Review  the  Shipbuilder’s  master  schedule  of  key  events  and 
production  milestones. 


Discuss  program  planning  with  the  Program  Office  acquisition 
manager,  technical  director/integration  manager  (if 
applicable),  test  and  evaluation  manager,  technology 
manager,  logistics  manager,  and  business  and  financial 
manager. 


Identify  design  requirements,  constraints  and  ensure  they  are 
sufficiently  defined  to  support  this  design  phase. 


Establish  design  budgets  as  required. 


Establish  requirements  traceability. 


Establish  Technical  Performance  Measures. 


Define  design  phase  entrance/exit  criteria  such  as  the  degree 
of  ship  system  definition  and  design  products. 


Develop  Engineering  Management  Plan  and  inputs  for  the 
Program  System  Engineering  Plan. 


Establish  minimum  reporting  requirements  and  guidelines. 


Consult  lessons  learned  for  past  programs  and  “best 
practices.” 


Establish  Action  Item  Tracking. 


Establish  Risk  Management. 


Develop  WBS. 


Develop  physical  and  software  architectures. 


Establish  Design  Team  organization. 


Make  contact  with  SEA  05C  to  discuss  design  inputs  required 
for  cost  estimating. 


X 

X 

X 

X 

X 

X 

For 

Industry 

Design 

For 

Industry 

Design 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 
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ACTION 


Make  contact  with  AoA  Study  Director,  and  begin  discussion 
of  support  studies  required. 


Review  data  from  ship  design  project  history  book  (the  Red 
Book)  and  annual  reports  (copies  are  in  the  SEA  05D/V 
library)  to  determine  rough  data  for  schedule  and  funding 
requirements. 


Conduct  Design  Activity  Modeling,  Develop  DSM,  Produce 
Integrated  Master  Schedule  with  Critical  Path  and  Resourcing. 


Focus  on  development  and  approval  of  mission  scenarios, 
threat  sets,  concept  of  operations  and  design  reference 
mission. 


Begin  discussion  of  Corrosion  Control,  ESOH,  HSI,  RAM-C 
and  other  horizontal  activities  and  potential  support. 


Prepare  memo  from  Division  Director  to  SEA  05DA/ 
requesting  project  support  personnel. 


Set  up  meeting  with  PNA  or  DIM  and  SEMs  to  define  the  task 
and  to  establish  relationships  and  responsibilities. 


Determine  design  strategy  for  use  of  contractor  support. 
Evaluate  potential  OCI. 


Determine  and,  if  required,  arrange  for  Shipbuilder 
participation. 


Evaluate  the  need  for  Fleet,  INSURV,  and  other 
organizational  participation. 


Determine  need,  and,  as  necessary,  prepare  letter  to  and/or 
negotiate  MOU  or  MOA  with  SPAWAR,  PEO  (C4I),  PEO  IWS, 
NAVSUP,  BUMED,  NAVAIR,  COMOPTEVFOR,  MSC,  ABS, 
USCG,  and  other  participating  organizations,  informing  them 
of  the  design  effort  and  requesting  a  liaison  point  of  contact. 


Establish  relationship  with  SUPSHIP  office  to  define  roles  and 
responsibilities. 


Complete  planning  for  independent  design  assessment. 


Complete  Design  Team  staffing  planning. 


Identify  the  need  for  a  Design  Site  and  obtain  pricing. 


Identify  the  need  to  establish  an  IDE  and  obtain  pricing. 


Prepare  memo  requesting  SOWs  and  WTAs  from  each  TL. 
Forward  same  through  the  appropriate  SEM.  Complete. 


Prepare  budget  and  obligation  plan.  Negotiate  the  basis  for 
funds  transfer  from  the  Program  Office.  Establish  an  AEA 
with  the  Program  Office. 


Establish  the  financial  management  system  for  the  project 
including  budgeting,  tracking,  and  reporting. 


Pre-PD  PD  CD  DD&C 


X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

For 

Industry 

Design 

For 

Industry 

Design 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 
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ACTION 

FS 

Pre-PD 

PD 

CD 

DD&C 

Request  SEMs  obtain  names  of  TLs  and  functional  code 
contacts.  Distribute  to  all  team  members. 

X 

X 

X 

X 

X 

Establish  project  data  management  system  and  IDE,  including 
provisions  for  action  items,  documentation  management, 
requirements  traceability,  and  design  history. 

X 

X 

X 

X 

X 

Verify  that  the  Shipbuilder’s  IDE  is  ready  to  support  DD&C. 

X 

Determine  modeling  and  simulation  and  associated  VV&A  to 
be  employed. 

X 

X 

X 

X 

Select  design  tools  to  be  used.  Consider  CAD  system 
compatibility. 

X 

X 

X 

X 

Identify  design  standards  and  margins  to  be  employed. 

X 

X 

X 

X 

Determine  subsystems  having  high  risks  or  a  potentially 
significant  impact  on  ship  performance,  configuration,  weight, 
cost,  or  manpower,  personnel,  and  training  requirements  so 
emphasis  can  be  placed  on  these  subsystems. 

X 

X 

X 

X 

X 

Using  the  DRL  deliverable  schedule,  prepare  a  list  of  DRLs 
requiring  review  and  approval  by  headquarters  that  includes 
the  schedule  for  the  review  and  who  is  responsible  for  the 
review.  Forward  to  the  Design  Team. 

For 

Industry 

Design 

For 

Industry 

Design 

For 

Industry 

Design 

X 

Establish  relationships  with  PARMs  and  other  supporting 
activities  on  information  necessary  for  design  and  to  establish 
manpower,  personnel,  and  training  requirements. 

X 

X 

X 

X 

Review  Program  Office  schedule  for  GFE/GFI.  Continue  to 
update  as  delivery  dates  are  firmed  up. 

X 

X 

Hold  kick-off  meeting  with  entire  Design  Team  to  ensure 
everyone  has  the  same  understanding  of  the  job  to  be  done 
and  to  define  clearly  specific  design  directions  and 
responsibilities.  Cover  preparation  of  SOWs/WTAs  and  start 
of  tasking  document  preparation  for  contractor  support. 
Distribute  copies  of  the  Engineering  Management  Plan  and 
any  other  design  requirements  or  restraints  imposed  by 

OPNAV  or  the  Program  Office.  Follow  up  with  memo  and 
subsequent  management  review  meetings. 

X 

X 

X 

X 

X 

Identify  required  studies,  analyses,  model  testing,  and 
associated  technical  reports. 

X 

X 

X 

X 

X 

Coordinate  to  ensure  appropriate  participation  in 
implementation  of  ship  master  test  plan. 

For 

Industry 

Design 

X 

Review  and  sign  out  all  tasking  documents  for  design  support. 

X 

X 

X 

X 

X 

Schedule  weekly  or  other  regular  meetings  with  SEMs  and 
Project  Office  personnel  to  keep  clear  lines  of  communication. 
Send  out  memo  with  schedules  and  identify  those  who  are 
expected  to  attend. 

X 

X 

X 

X 

Develop  master  calendar  and  procedures  for  status  reports 
and  action  items. 

X 

X 

X 

X 

X 
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ACTION 

FS 

Pre-PD 

PD 

CD 

DD&C 

Establish  configuration  control  system,  including  requirements 
traceability  and  design  history. 

X 

X 

X 

X 

Define  and  document  security  classification  requirements. 
Develop  Program  Protection  Plan. 

X 

X 

X 

X 

X 

Establish  a  Design  Decision  Memorandum  or  equivalent 
process. 

X 

X 

X 

X 

X 

Determine  schedule  for  design  reviews  and  reviews  by  senior 
level  personnel  and  establish  procedures  to  be  followed. 

X 

X 

X 

X 

X 

The  following  reviews  should  be  scheduled  and  documentation  developed: 

In-process/peer  reviews 

X 

X 

X 

X 

X 

Participate  in  contractor  or  Shipbuilder  design  reviews. 


Identify  award  fee  criteria  and  participate  on  the  award  fee 
board. 


Monitor  Shipbuilder’s  management  of  design  margins. 


Participate  in  development  and  review  of  ECPs  and  Requests 
for  Clarification,  Information  and  Assistance  (RCIAs)  in 
support  of  CCB  evaluation  and  approval. 


Coordinate  SEA  05  review  and  comment  on  DRL 
deliverables. 


Obtain  feedback  from  INSURV,  the  Fleet,  COMOPTEVFOR, 
and  safety  center  on  problems  with  similar  ships  or 
equipment. 


Participate  in  INSURV  inspection  and  arrange  for  technical 
support  during  and  after  it.  Obtain  feedback  for  use  in  follow 
ships. 


Task  development  of  design  notebooks. 

X 

X 

X 

Develop  and  implement  procedure  for  formal  and  informal 
management  briefings  and  problem  reporting. 

X 

X 

X 

X 

X 

Develop  and  implement  a  system  for  progress  reporting  and 
financial  status  -  overall  status  as  well  as  status  by 

SOW/WTA. 

X 

X 

X 

X 

X 
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ACTION 


Develop  and  schedule  presentations  to  the  Fleet  on  significant 
features  of  the  design.  Also  schedule  INSURV  presentations 
when  appropriate  for  the  design  (major  combatant  ship 
designs). 


Keep  SEA  05C  informed  of  design  and  design  changes,  and 
get  periodic  updates  on  ship  acquisition  cost  estimates. 


Participate  in  SEA  05C  cost  estimate  peer  reviews. 


Prepare  final  design  report. 


Receive  Ship  Specification  certification  sheets  from  TLs 
through  the  SEMs. 


For  final  approval  of  the  design  package  determine: 
What  will  be  signed 
Who  will  sign  each  document 
Correct  signature  blocks 
Attendance  at  signature  ceremonies 
Distribution  of  signed  copies. 


Participate  in  development  of  SOW  and  other  contract 
documentation. 


Participate  in  source  selection. 


Determine  disposition  of  project  records. 


Prepare  SEA  05D/V  annual  report. 


Work  with  SEA  05S  to  develop  the  Specification  Development 
Plan. 


Work  with  SEA  05S  to  develop  the  Specifications  Matrix. 


Chair  the  Reading  Session. 


Review  the  Reading  Session  Plan. 


Get  the  Master  Index  of  References. 


Work  with  SEA  05S  on  Specification  Training. 


Work  with  the  Program  Manager  on  Specification  Type 
Selection. 


Get  a  Specification  Delivery  Schedule  from  the  Shipbuilder. 


Pre-PD  PD  CD  DD&C 


For  For 

Industry  Industry 

Design  Design 
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APPENDIX  A 

SHIP  DESIGN  AND  ACQUISITION  DIRECTIVES  AND  REFERENCES 

Acquisition  Management 

Federal  Acquisition  Regulation 

Defense  Federal  Acquisition  Regulation  Supplement 

DoD  Directive  5000.01,  The  Defense  Acquisition  System,  12  May  2003  (Certified  current  as  of  20  November 
2007) 

DoD  Instruction  5000.02,  Operation  of  the  Defense  Acquisition  System,  8  December  2008 
Defense  Acquisition  Guidebook,  5  May  2010 

SECNAVINST  5000.2E,  Implementation  and  Operation  of  the  Defense  Acquisition  System  and  the  Joint 
Capabilities  Integration  and  Development  System,  1  September  2011 

SECNAV  M-5000.2,  Department  of  the  Navy  Acquisition  and  Capabilities  Guidebook,  22  December  2008 

SECNAVINST  5400. 15C,  DoN  Research,  Development  and  Acquisition,  and  Associated  Life  Cycle  Management 
Responsibilities,  13  September  2007 

Aviation 

OPNAVINST  3120.28B,  Certification  of  Aviation  Capability  of  Ships  Operating  Aircraft,  21  October  1991 

OPNAVINST  3120.35J,  Requirements  for  Air  Capable,  Amphibious  Assault,  and  Mine  Countermeasures  Ships 
to  Operate  Aircraft,  27  June  2000 

C4I 

OPNAVINST  2300.44G,  Communications  Characteristics  for  Navy  Ships,  MSC  Ships,  Coast  Guard  Cutters, 
Designated  Craft,  Portable  Radio  Users  and  Major  Shore  Communications  Stations,  23  June  2007 

OPNAVINST  3090. 1,  (C4I)  Capability  Requirements  Definition  For  New  Construction  And  Intelligence 
Systems  Program  Roadmap,  5  October  2009 

Configuration  Management 

NAVSEAINST  4130.12B,  Configuration  Management  (CM)  Policy  and  Guidance,  21  July  2004 

Commonality 

NAVSEAINST  4120.8,  NAVSEA  Policy  for  Commonality  of  Systems,  Subsystems,  and  Components,  6  Apr 
2009 
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Contracting 

USD  (AT&L)  Memo  Strengthened  Sustainment  Governance  for  Acquisition  Program  Reviews,  5  April  2010 
NAVSEAINST  4200.03B,  Unsolicited  Proposals  Processing,  14  January  1988 
NAVSEAINST  4200. 17C,  Contracting  Officer’s  Representative  (COR),  20  January  2006 
NAVSEAINST  4200.19,  Service  Contract  Restrictions  &  Safeguards,  25  January  1990 

NAVSEAINST  5400.57D,  Engineering  Agent  Selection,  Assignment,  Responsibility,  Tasking  and  Appraisal,  3 
February  2003 

USD  RD&A  Memo  Rescission  of  Award  Fee  Contracts  Memoranda,  31  January  2011 

USD  RD&A  Public  Disclosure  of  Justification  and  Approval  Documents  for  Non  Competitive  Contracts,  24 
February  2009 

USD  RD&A  Memo  Department  of  the  Navy  Peer  Review  Program,  26  March  2009 

USD  RD&A  Memo  DoDIG  Contracting  Action  Areas  of  Concern,  Purchases  Made  With  Earmarks,  28 
September  2010 

USD  RD&E  Memo  Required  Documented  and  Signed  Component  Level  Cost  Position  for  Milestone  Reviews,  12 
March  2009 

Correspondence  and  Records  Management 

DoD  Directive  5230.24,  Distribution  Statements  on  Technical  Documents,  18  March  1987 
NAVSEAINST  5200.1 1  A,  Decision  Process  and  Format,  17  December  1986 
NAVSEAINST  5230.012,  Release  of  Information  to  the  Public,  21  November  2003 
NAVSEAINST  5730.01D,  Legislative  &  Congressional  Matters,  18  July  2002 
SECNAV  Manual  M-5216.5,  Navy  Correspondence  Manual,  March  2010 

NAVSEAINST  5216.02B,  Signature  Authority  for  Correspondence,  Directives,  and  Naval  Messages,  30  June 
1986 

SECNAV1NST  5210.8D,  Department  of  the  Navy  Records  Management  Program,  31  December  2005 
NAVSEAINST  5200.1 1A,  Decision  Process  and  Format,  17  December  1986 
NAVSEAINST  5210.5,  Records  Management,  3  April  1997 

Corrosion  Prevention 

NAVSEAINST  9630.001,  Corrosion  Prevention  and  Control  Policy,  2  March  2006 

Cost  Estimating 

SECNAV1NST  5223.2,  Department  of  the  Navy  Cost  Analysis,  16  December  2008 
NAVSEAINST  7300. 14B,  Classification  of  Cost  Estimates  for  Ships,  16  May  1996 
DoD  Manual  5000.4-M,  Cost  Analysis  Guidance  and  Procedures,  December  1992 
DoD  Directive  5000.04,  Cost  Analysis  Improvement  Group,  16  August  2006 
NAVSEA  Cost  Estimating  Handbook 
USD  RD&A  Memo  Shipbuilding  Pricing,  19  February  2004 
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Data  Management/Integrated  Digital  Environment 

Guidance  on  Acquisition  and  Conversion  of  Logistics  Technical  Data  to  Digital  Form,  2004 

DoD  Manual  5010. 12-M,  Procedures  for  the  Acquisition  and  Management  of  Technical  Data,  May  1993 

NAVSEAINST  4130.12B,  Configuration  Management  Policy  and  Guidance,  21  July  2004 

SECNAVINST  5200.39A,  Participation  in  the  Government-Industry  Data  Exchange  Program  (GIDEP),  23 
December  2005 

DoD  Directive  5230.24,  Distribution  Statements  on  Technical  Documents,  18  March  1987 
NAVSEAINST  4000.06A,  Data  Management  Program,  18  April  1989 

NAVSEAINST  9040.03,  Development,  Maintenance,  and  Exchange  of  Product  Model  Data  by  Ship  and  System 
Programs,  4  March  1998 

NAVSEAINST  9085.003A,  Selected  Record  Drawings  for  Ship  Acquisition,  12  September  1989 
NAVSEAINST  9085.04,  Engineering  Drawing  Technical  Data  Package  Acquisition  Requirements,  20  May  1988 
NAVSEAINST  9085.01,  Standard  and  Type  Drawings,  1  March  1983 

OPNAVINST  4120.5,  DoN  Computer-Aided  Acquisition  and  Logistics  Support  (CALS)  Policy  and  Signature 
Plan,  1  July  1992 

SECNAVINST  5000.37,  Provision  of  Department  of  the  Navy  Documentary  Material,  21  September  2009 

Design 

SEA  05D  Memo,  serial  05D/376  of  28  June  2010,  Surface  Ship  Concept  Design  Policy 
NAVSEA  Memo,  serial  05D/386  of  30  June  2010,  Technical  Decision  Process 
Concept  Design  Handbook  version  1 .0,  27  December  2006 

SEA  05D  Memo,  serial  05D/023  of  31  January  2005,  System  to  Categorize  Concept  and  Feasibility  Study  Efforts 

SEA  05D  Memo,  serial  05D/135  of  22  November  2004,  Internal  Review  Release  Process  for  Ship  Concepts 

SECNAVINST  5031. 1C,  Ship  Naming,  Keel  Layings,  Christenings,  Commissioning  and  Decommissioning,  29 
September  2009 

USD  AT&L  Standardization  of  Work  Breakdown  Structures  to  Support  Acquisition  Program  Management,  9 
January  2009 

Ser  05B/066  of  17  November  2009,  SEA  05  Policy  on  Review  and  Approval  of  Products  For  Distribution  Outside 
Naval  Systems  Engineering  Directorate 

Naval  Engineers  Journal,  May  1983  paper  Repeat  Ship  Designs  Facts  and  Myths  by  Phil  Covich  and  Michael 
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SL720-AA-MAN-030,  Surface  Ships  and  Carriers  Entitled  Process  for  Modernization  Management  and 
Operations  Manual 

Integrated  Project  Teams  for  Aircraft  Carrier  Maintenance  (IPT4ACM) 

COMFLTFORCOMINST  4790.3,  Joint  Fleet  Maintenance  Manual  (JFMM) 

Habitability 

OPNAVINST  9640. 1  A,  Shipboard  Habitability  Program,  3  September  1996 

Human  Systems  Integration 
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OPNAVINST  3000. 12A,  Operational  Availability  of  Equipments  and  Weapons  Systems,  2  September  2003 
USD  RD&A  Memo  Reliability,  Availability  and  Maintainability  Policy,  26  August  2008 
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NAVSEAINST  9093. 01C,  Combat  System  Ship  Qualification  Trials  for  Surface  Ships,  30  August  2006 

NAVSEAINST  9094.05,  Ship  Performance  Trials,  14  June  1985 

OPNAVINST  4730.5Q,  Trials  and  Material  Inspections  (MI)  of  Ships  Conducted  by  the  Board  of  Inspection  and 
Survey,  23  February  2010 

Topside 

NAVSEA  05  Memorandum  9830  Ser  05D/312  of  1 1  October  2007,  Integrated  Topside  Design  and  Certification 
Process  for  New  Construction  Ships 

NAVSEAINST  9700.02,  Integrated  Topside  Safety  and  Certification  Program  for  Surface  Ships,  1 1  September 
1998 

ASN  (RD&A)  and  VCNO  Joint  Letter,  Topside  Integration  and  Certification  Policy  for  Surface  Ships,  7  Oct  2002 
ASN  (RD&A)  memo,  Surface  Ship  Topside  Design  Principles,  1  August  2005 

Training 

OPNAVINST  1500.76B,  Navy  Training  System  Requirements,  Acquisitions,  and  Management,  28  April  2010 

OPNAVINST  3500.23D,  Assembly,  Organization,  and  Training  of  Crews  for  the  Commissioning  of  U.S.  Navy 
Ships,  16  March  2010 

Underwater  Ship  Husbandry 

ASN  (RD&A)  letter  of  24  March  2006 
Weapons  System  and  C4ISR  Integration 

NAVSEA  05H  and  PEO  IWS  Technical  Review  Manual  (TRM) 

NAVSEAINST  9410.2,  Naval  Warfare  Systems  Certification  Policy 

PEOIWSINST  4130.1,  Integrated  Warfare  Systems  (IWS)  Enterprise  Configuration  Control  Process 
COMUSFLTFORCOMINST/COMPACFLT  4720.3  C5ISR  Modernization  Policy 
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Weight  Management 

NAVSEAINST  9096. 6B,  Policy  for  Weight  and  Vertical  Center  of  Gravity  Above  Bottom  of  Keel  (KG)  Margins 
for  Surface  Ship.  16  August  2001 

NAVSEA  Weight  Control  TWH  policy  summary  presentation,  Weight  and  Vertical  Center  of  Gravity  Margin 
Policy  for  Surface  Ships,  19  June  2007 

OPNAVINST  9096.1,  Weight  and  Stability  Limits  for  Naval  Surface  Ships,  12  November  1985 

Work  Breakdown  Structure 

NAVSEAINST  4790.01B,  Hierarchical  Structure  Codes  (HSC)  for  Ships,  Ship  Systems  &  Surface  Combatant 
Systems,  10  April  2007 

MIL-STD-881,  DoD  Handbook  -  Work  Breakdown  Structure,  14  January  201 1 
S9040- AA-IDX-0 1 0/S WBS  5D  Expanded  Ship  Work  Breakdown  Structure 
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APPENDIX  B 

EXPLORATORY  DESIGN  AND  FORCE  ARCHITECTURE  STUDIES 

Exploratory  Design  and  Force  Architecture  Studies  are  undertaken  prior  to  program  starts.  These  efforts 
anticipate  overall  future  needs  without  requiring  each  program  to  undertake  the  burdensome  effort  of  divining  the 
future.  These  expand  the  base  of  knowledge  upon  which  assessments  of  the  bounding  capabilities  of  naval-based 
forces  are  made.  In  short,  they  provide  a  means  to  accurately  characterize  the  “art  of  the  possible.”  Such  studies 
are  short  in  duration,  notably  lacking  in  specifics.  They  may  be  done  as  concept  or  even  feasibility  level  ship  and 
system  studies  to  explore  novel  concepts  or  the  application  of  new  technologies;  POM  studies  to  support  insertion 
of  ship  programs  into  the  Ship  Construction  Navy  (SCN)  plan  or  Expanded  Planning  Annex;  or  platform  level 
trade  studies  of  varying  sets  of  requirements  applied  to  a  range  of  platforms  for  the  purposes  of  studying  force 
architecture  and  influencing  future  force  composition.  Many  times  theses  studies  are  conducted  by  innovation 
cells  in  support  of  war  games  and  external  customers  like  the  Navy  Warfare  Development  Command  and  the 
Chief  of  Naval  Operations  Strategic  Studies  Group  or  specific  Resource  Sponsors.  The  results  of  such  studies 
must  be  reviewed  for  completeness,  accuracy,  and  conformance  with  high-level  design  policies,  including  cross 
platform  interoperability. 

A  SCM  normally  leads  these  studies  using  a  small  team  of  just  a  few  engineers  including  where  applicable  SIM 
participation.  Generally  a  synthesis  tool  such  as  ASSET  will  provide  the  bulk  of  the  design  data  and  analysis  for 
these  designs.  Prospective  SDM(s)  must  keep  informed  of  this  work  for  its  impact  on  future  designs  and  possible 
information  of  use  in  ongoing  designs.  Prospective  SDM(s)  or  Division  Director(s)  will  normally  be  given  the 
opportunity  to  review  and  comment  on  results  by  attending  the  design  reviews  and  reviewing  the  reports. 

See  SEA  05D  Memo  9830  Ser  05D/376  of  28  June  2010,  Surface  Ship  Concept  Study  Policy  ( hyperlink ),  and  the 
Concept  Design  Handbook  Version  1 .0  of  27  December  2006  for  specific  guidance  on  the  performance  of  concept 
design.  SEA  05D/135  of  22  November  2004  ( hyperlink )  details  an  internal  review  process  which  helps  maintain 
the  quality  and  consistency  of  concept  studies.  A  system  for  categorizing  concept  and  feasibility  study  efforts, 
introduced  in  Ser  SEA  05D/023  of  31  January  2005  ( hyperlink ),  assists  in  tailoring  the  studies  to  meet  customer 
expectations. 

In  order  to  rigorously  flow  down  mission  performance  requirements  to  the  individual  ship  level,  the  analysis  of 
ship  concept  alternatives  must  be  carried  to  the  next  higher  level,  which  is  the  battle  group  or  strike  force.  In 
many  cases,  a  new  ship  design  is  initiated  for  the  puipose  of  replacing  ships  with  the  same  mission  that  are 
approaching  the  end  of  their  expected  service  lives.  Force  level  assessments  in  this  case  are  fairly 
straightforward.  The  new  ship  is  basically  a  functional  replacement  for  the  ship  to  be  retired,  albeit  with  upgrades 
to  account  for  changes  in  statute,  Navy  policy  and  standards  (e.g.,  new  shipboard  habitability  standards  or  margin 
policy),  and  state-of-the-art  improvements  in  command,  control,  communications,  and  combat  systems. 

Study  Guide  should  be  developed  and  approved  prior  to  beginning  work.  Successful  reviews  of  feasibility  studies 
often  depend  on  the  level  of  confidence  the  reviewers  have  in  these  early  parametric  design  tools  and  the 
experience  of  their  operators.  Thus,  interim  “peer”  reviews  should  be  conducted  with  applicable  technical  codes 
and  key  stakeholders  early  and  often  as  the  studies  progress  to  build  up  credibility  rather  than  waiting  until  the 
end  of  the  design  efforts.  Study  results  should  be  documented  in  a  formal  report. 
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APPENDIX  C 

PRE-ANALYSIS  OF  ALTERNATIVES  STUDIES 

Prior  to  beginning  an  AoA,  a  small  Design  Team  lead  by  an  SCM  and  including  a  few  engineers  and,  where 
applicable,  SIM  participation,  will  generally  begin  to  develop  multiple,  high-level  ship  concept  or  feasibility  level 
designs  to  investigate  the  impact  of  trading  off  requirements  on  ship  performance,  size,  and  cost.  Note  that  for 
modified  repeats  these  design  efforts  generally  involve  modifications  of  existing  Contract  and  Detail  Design  level 
arrangements,  weight  statements,  and  other  design  artifacts  rather  than  reverting  to  the  use  of  ASSET  or  other 
early  stage  design  tools. 

These  efforts  support  formulation  of  a  mission  need  during  conduct  of  a  Capabilities  Based  Assessment  (CBA), 
Senior  Warfighter  Forum  (SWARF),  or  comparable  functional  analysis.  The  analysis  results  are  recorded  in  an 
ICD.  Then  an  MDD  typically  results  in  kickoff  of  an  AoA.  Technology  assessment  and  any  required  technology 
development  continues. 

This  is  a  good  time  to  focus  on  development  and  approval  of  mission  scenarios  and  the  Concept  of  Operations 
(CONOPS).  This  is  an  important  prerequisite  for  conduct  of  the  AoA.  Programs  like  MPF(F)  have  experienced 
difficulties  conducting  a  useful  AoA  and  then  proceeding  with  requirements  definition  when  the  basic 
assumptions  of  how  the  ship  will  be  employed  have  not  been  established.  A  Design  Reference  Mission  (DRM) 
should  be  employed  to  characterize  the  CONOPS  in  terms  of  the  ship  requirements  for  speed,  endurance,  stores, 
and  other  characteristics.  The  CONOPS  and  DRM  are  often  developed  by  the  SDM  out  of  necessity  but  still  need 
to  be  approved  by  the  Program  Office  and  Sponsor.  There  is  a  draft  OPNAV  Instruction  prescribing  CONOPS 
format. 

This  is  also  a  good  time  to  focus  on  the  development  and  approval  of  threat  sets  that  will  be  used  in  survivability 
and  later  live  fire  test  and  evaluation  assessments.  This  is  an  important  prerequisite  for  conduct  of  the  AoA,  PD, 
and  CD.  Survivability  design  approaches  should  also  be  vetted  with  Technical  Warrant  Holders  during  this  stage 
in  preparation  for  AoA  kickoff. 

It  is  also  during  this  phase  that  Pass  1  of  the  Six-Gate  Process  begins.  Gate  1  grants  authority  for  the  DoN- 
initiated  ICD  that  has  completed  Navy  review  to  be  submitted  to  the  Joint  Staff  (J-8)  for  routing  using  the  JCIDS. 
Gate  1  will  also  validate  the  proposed  AoA  Guidance  and  authorize  a  program  to  proceed  to  the  MDD. 

Design  efforts  should  be  preceded  by  development  and  approval  of  a  Pre-AoA  Engineering  Management  Plan  and 
study  guide(s).  Development  of  an  Engineering  Management  Plan  this  early  hasn’t  typically  been  done  before  but 
the  SDM  has  ended  up  doing  equivalent  planning  anyway  which  would  benefit  from  being  more  formally 
documented.  Event-based  design  reviews  should  be  scheduled  at  the  peer  level  including  participation  by  the 
prospective  Program  Office,  OPNAV  Sponsor,  TWHs,  other  supporting  technical  codes,  and  stakeholders.  As 
detailed  in  Appendix  Q,  a  formal  Initial  Technical  Review  (ITR)  in  conjunction  with  a  Technical  Review  Board 
(TRB)  and  Stakeholder  Steering  Board  (SSB)  should  be  held  prior  to  submission  of  the  ICD  to  Navy  staffing  to 
review  the  technical  inputs  to  the  ICD  and  planning  for  the  AoA.  A  formal  design  report  should  be  written  to 
document  design  phase  results. 
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APPENDIX  D 

ANALYSIS  OF  ALTERNATIVES  STUDIES 

The  MDD  will  initiate  the  Materiel  Solution  Analysis  Phase  shown  in  Figure  2- 1 .  Materiel  Solution  Analysis 
consists  of  an  AoA  and  supporting  studies  whose  objectives  are  to  define  a  set  of  feasible  alternative  whole  ship 
solutions  to  a  set  of  operational  requirements.  AoA  options  considered  must  span  the  full  range  of  reasonable 
possibilities,  including  performance,  cost,  and  risk.  The  AoA  must  identify  early  those  elements  of  performance 
that  are  major  cost  drivers  and  their  underlying  requirements.  This  is  critical  to  the  design  process  and  provides 
valuable  feedback  to  the  OPNAV  Sponsor,  who  will  review  the  requirements  and  make  necessary  adjustments  to 
the  developing  CDD. 

Generally,  the  studies  are  lead  by  an  SCM  or  SDM  and  conducted  by  a  small  team  -  one  to  three  full  time 
equivalents  with  SIM  participation  as  applicable  over  three  to  12  months.  However,  this  may  vary  depending  on 
the  number  of  alternatives  considered  and  the  specific  program  schedule  constraints.  They  are  based  on  a 
selected,  broadly-stated,  ship  mission  and  a  set  of  minimum  capabilities  as  documented  in  the  ICD.  The  studies 
are  usually  done  in  the  context  of  a  desired  schedule  for  design  and  construction.  This  design  phase  provides  the 
technical  definition  basis  for  a  Rough  Order  of  Magnitude  (ROM)  or  Feasibility  level  cost  estimate.  Once  a 
design  alternative  is  selected,  it  is  necessary  to  proceed  into  a  more  thorough  analysis  to  validate  and  refine  it. 

In  the  case  of  “mod-repeat”  designs,  feasibility  studies  will  be  based  on  an  existing  design  that  is  to  be  modified 
and  built  as  new  construction  (i.e.,  “forward  fit”).  The  constraints  of  existing  designs  coupled  with  the  evolution 
of  design  practices  and  standards  since  the  baseline  design  was  completed  often  present  challenges.  In  such  cases, 
ensuring  feasibility  means  taking  the  design  to  a  finer  level  of  detail  than  for  a  “clean  sheet  of  paper”  design  based 
on  parametric  predictions.  CG47  is  a  good  example  of  how  much  effort  is  required  to  develop  highly  adapted 
mod-repeats.  It  took  2.5  years  from  start  of  feasibility  studies  (then  called,  “concept  design”)  to  completion  of  the 
Materiel  Solution  Analysis  and  had  as  large  a  Design  Team  as  the  DDG51,  which  took  4.3  years  for  the  same 
phases. 

Typical  study  output  will  start  to  go  beyond  the  ASSET  level  -  with  PowerPoint  level  topside,  outboard  profile, 
and  inboard  profiles  arrangements  showing  the  major  weapons  systems  and  topside  items  along  ship  volume 
allocations  and  with  weight  and  space  estimates.  Development  of  major  equipment  lists  has  begun.  Ship 
manning  estimates  are  needed  but  not  typically  high  fidelity  at  this  point.  Consequently,  ship  accommodations 
are  often  imprecise.  These  products  are  needed  for  the  cost  forms  developed  for  SEA  05C  procurement  and  life 
cycle  cost  estimating  and  the  PowerPoint-type  briefing  material  developed  for  the  AoA  Integrated  Product  Team 
and  Executive  Steering  Committee  or  Senior  Advisory  Group.  See  Appendix  P  for  a  listing  of  typical  design 
deliverables.  Much  remains  to  be  defined.  Thus,  significant  margins  should  be  included  to  allow  for  future 
design  definition.  Current  Navy  margin  policy  is  summarized  in  Part  0,  Chapter  10  of  the  American  Bureau  of 
Shipping  Naval  Vessel  Rules  (ABS  NVR). 

A  formal  risk  management  process  should  commence  late  in  the  AoA  to  support  conduct  of  the  subsequent  Gate  2 
and  Milestone  A.  It  normally  follows  the  standard  approach  typified  in  Defense  Systems  Management  College 
literature  and  widely  used  on  other  ship  design  programs  in  which  risk  “waterfall”  or  “bumdown”  paths  are 
generated  to  depict  the  steps,  schedule,  and  resources  needed  for  risk  mitigation.  Areas  perceived  as  having 
significant  risk  need  to  be  identified;  mitigation  strategies,  including  fallback  plans,  have  to  be  defined.  Potential 
risks  that  will  need  to  be  specifically  addressed  at  the  post  AoA  Gate  2  review  and  Milestone  A  include 
affordability,  technology  readiness,  and  the  adequacy  of  the  industrial  base.  The  Program  should  also  be  prepared 
to  demonstrate  that  they  have  begun  planning  for  ESOH,  HSI,  sustainability,  energy  efficiency,  open  systems,  and 
the  other  design  considerations  appropriate  to  subsequent  design  efforts. 
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As  soon  as  a  Program  Office  has  been  established,  it  will  normally  become  the  releasing  authority  for 
correspondence  and  other  external  communications.  The  SDMs  must  be  compliant  with  both  SEA  05  and 
Program  Office  protocols  for  communications  with  other  organizations,  adhering  to  the  most  stringent 
requirements  of  each.  Specific  instructions  have  been  issued  governing  internal  routing,  formal  review,  and 
approval  of  acquisition  program  documents  and  official  correspondence  before  official  program  responses  are 
forwarded.  In  addition  cognizant  TWHs’  concurrence  shall  be  ensured  by  the  SDM  and  or  SIM  before  reporting 
results  which  are  high  risk  or  likely  to  be  controversial. 

Design  efforts  should  be  preceded  by  development  and  approval  of  an  AoA  Engineering  Management  Plan  and 
study  guide(s).  Event-based  design  reviews  should  be  scheduled  at  the  peer  level  including  participation  by  the 
prospective  Program  Office,  OPNAV  Sponsor,  TWHs,  other  supporting  technical  codes,  and  other  stakeholders. 
An  Alternative  Systems  Review  (ASR)  in  conjunction  with  a  TRB  and  SSB  should  be  conducted  prior  to 
completion  of  the  AoA  to  review  the  technical  inputs  to  the  AoA.  See  Appendix  P.  A  formal  design  report 
should  be  written  to  document  design  phase  results. 

The  Gate  2  review  to  review  the  results  of  the  AoA  will  occur  after  completion  of  the  AoA  and  prior  to  a  Program 
submitting  Milestone  A  documentation.  At  Milestone  A,  an  MDA  review  will  be  held  to  evaluate  the  results  of 
the  AoA,  technology  maturity,  technical  risk,  and  international  availability  or  potential  for  international 
cooperation;  to  approve  the  preferred  system  solution  and  technology  development  strategy;  and  to  authorize 
entry  into  the  Technology  Development  Phase. 

Early  development  and  approval  of  a  CDD  immediately  following  the  AoA  may  be  accomplished  to  focus  design 
efforts.  If  so,  conduct  of  a  System  Requirements  Review  (SRR)  in  conjunction  with  a  TRB  and  SSB  and 
submission  of  the  CDD  to  Navy  staffing  may  precede  Milestone  A.  Gate  3  should  proceed  when  approval  for  the 
CDD  to  enter  Joint  staffing  is  needed.  Early  Program  Initiation  at  Milestone  A,  however,  may  not  be  desirable 
since  it  would  require  premature  development  and  approval  of  several  planning  documents  additional  to  the  CDD. 
Depending  on  the  acquisition  strategy,  Pre -Preliminary  Design  and  even  Preliminary  Design  may  start  prior  to 
Milestone  A. 

Concurrent  development  and  approval  of  the  Test  and  Evaluation  Strategy  should  also  happen  during  this  phase 
prior  to  Milestone  A.  It  is  a  good  time  to  focus  on  development  of  developmental  testing  and  life  fire  test  and 
evaluation  strategies  and  key  events. 
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APPENDIX  E 

PRE-PRELIMINARY  DESIGN 

At  the  conclusion  of  the  AoA,  recent  experience  has  shown  that  there  is  often  not  sufficient  design  detail  or 
requirements  definition  to  complete  a  Milestone  A  or  enter  into  Preliminary  Design.  Thus  Preliminary  Design 
may  be  preceded  by  a  Pre-Preliminary  Design  stage  employing  either  Set-Based  Design  methods  or  the  creation 
of  an  Indicative  Design  to  validate  that  the  design  requirements  developed  in  the  AoA  are  achievable  within  the 
framework  of  an  acquisition  program.  For  an  Indicative  Design,  this  is  done  through  development  of  a  single 
design  solution,  a  feasible  though  not  necessarily  optimal  solution  to  the  design  requirements  that  is  within  the 
program  parameters  of  ship  size,  cost,  and  performance.  Indicative  designs  are  most  often  developed  using  a 
parametric  ship  synthesis  modeling  tool  and  other  methods  that  rely  on  information  from  past  similar  or 
comparable  designs.  In  a  Set-Based  Design  approach,  the  design  requirements,  CONOPS,  and  different 
disciplines  of  ship  design  are  developed  concurrently.  Information  of  each  area  is  conveyed  to  the  design 
integrator  in  the  form  of  feasible  sets.  The  range  of  possible  design  solutions  is  determined  by  the  intersection  of 
these  different  sets.  At  each  design  gate,  the  design  space  is  reduced  to  eliminate  regions  where  the  optimal 
solutions  are  likely  not  to  reside.  Each  area  is  then  refined  by  increasing  the  level  of  detail  to  enable  further 
reductions  in  the  design  space.  At  the  end  of  this  design  stage,  the  goal  is  to  have  a  narrow  set  of  material 
solutions,  CONOPS,  and  requirements  that  meet  the  affordability  constraints. 

The  time  period  can  range  from  as  short  as  about  a  month  for  a  very  simple  design  to  a  year  or  longer  for  complex 
ships.  Since  this  phase  is  usually  the  first  part  of  a  ship  acquisition  program  of  record,  the  length  of  the  phase  is 
usually  set  by  the  acquisition  schedule  or  budget  available,  either  of  which  tends  to  limit  the  level  of  design  detail 
developed.  By  the  end  of  the  phase,  top-level  requirements  have  stabilized  and  a  CDD  should  have  been  drafted. 
This  is  sometimes  applied  as  the  first  phase  in  an  industry  led  competitive  design  process. 

Pre-Preliminary  Design  should  normally  be  led  by  an  SDM  with  roles  are  very  similar  to  those  for  the  feasibility 
studies  that  supported  the  AoA.  The  effort  will  be  in  considerably  more  depth  for  engineering  and  the  size  of  the 
Design  Team  will  be  just  starting  to  ramp  up  to  levels  required  to  support  Preliminary  Design.  For  competitive 
designs,  the  government  provides  industry  with  “insight”  rather  than  “oversight,”  in  most  cases  avoiding  giving 
specific  technical  direction  or  design  solutions  to  the  industry  teams.  The  technical  evaluations  are  provided  to 
the  Program  Manager  who,  in  turn,  decides  the  disposition  of  the  evaluation. 

While  initial  risk  reduction  activities  such  as  material  tests  or  industry  surveys  can  be  undertaken,  there  is  usually 
insufficient  total  ship  design  information  to  initiate  a  major  developmental  effort.  For  example,  the  specific 
horsepower  and  rpm  needed  in  a  new  engine  or  the  weight  limits  for  a  new  composite  structure  will  not  be 
finalized  until  near  the  end  of  the  phase.  Nevertheless,  performance  and  physical  characteristics  need  to  be 
estimated  and  acceptable  plans  for  fallbacks  (“off  ramps”)  developed  for  high  risk  and  high  ship  impact  items. 

The  design  should  permit  the  fallback  to  be  physically  accommodated,  usually  through  design  budgeting  (e.g., 
space,  weight,  and  support  systems  reservations).  Similarly,  margin  allocations  must  be  tailored  to  reflect  the 
magnitude  of  the  risks  caused  by  design  unknowns.  Farger  risks  require  larger  margins.  Weight  growths  of  50 
percent  or  more  are  not  uncommon  in  new  systems.  This  approach  also  needs  to  account  for  uncertainty 
introduced  by  applying  an  open  systems  approach  and  the  requirement  to  accommodate  open  competition  for 
major  elements  of  the  ship,  such  as  prime  movers.  That  means  it  generally  makes  sense  to  size  machinery  spaces 
applying  a  composite  worst-case  envelope  so  that  any  of  the  candidate  engines  in  a  range  of  performance  can  be 
fit  in  the  ship. 

Design  efforts  should  be  preceded  by  development  and  approval  of  a  Pre -Preliminary  Design  Engineering 
Management  Plan  and  study  guide(s).  Event-based  design  reviews  should  be  scheduled  at  the  peer  level  including 
participation  by  the  prospective  Program  Office,  OPNAV  Sponsor,  TWHs,  other  supporting  technical  codes,  and 
other  stakeholders.  A  formal  design  report  should  be  written  to  document  design  phase  results. 
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A  final  design  review  of  the  Pre -Preliminary  Design  should  be  scheduled  when  a  complete  and  balanced  design 
baseline  has  been  achieved  and  the  planned  work  for  this  phase  is  nearing  completion.  At  this  point,  the  ship  has 
been  sized  (displacement),  the  overall  ship  dimensions  are  generally  fixed,  major  subsystems  and  weapons  have 
been  selected  after  appropriate  trade  studies,  and  notional  descriptions  of  lower  level  systems  have  been 
developed,  often  relying  on  previous  or  similar  ship  experience.  In  general,  design  maturity  has  progressed  to  a 
state  where  a  feasible  solution  has  been  found  within  the  overall  program  parameters  of  ship  size,  cost,  and 
performance.  This  means  that  the  predicted  total  ship  system  capabilities  will  meet  the  CDD  and  there  are  no 
technical  “show  stoppers”  at  the  subsystem  level.  No  problems  are  anticipated  that  cannot  be  corrected  in 
subsequent  design  phases  within  the  total  program  constraints.  Subsequent  phases  will  evolve  the  design  from  a 
merely  feasible  solution  to  a  more  optimal  solution  and  some  changes  to  major  subsystems  may  still  be  needed  in 
the  next  phase  but  should  not  require  resizing  of  the  ship.  Please  see  additional  discussion  on  risk  below.  The 
CONOPS,  requirements,  materiel  solution,  and  cost  estimates  should  be  aligned. 

It  is  advisable  to  begin  selected  outside  reviews  during  this  phase,  such  as  with  the  WSESRB,  while  there  is  still 
much  design  flexibility.  Similarly,  Fleet  input  can  be  initiated,  particularly  for  quality  of  life  topics. 

If  not  performed  earlier,  the  SRR  should  proceed.  The  primary  objectives  of  this  review  can  be  stated  as  follows: 
“Are  the  system  level  requirements  clear,  complete,  compatible,  achievable,  and  affordable?”  From  an 
engineering  standpoint,  they  also  need  to  be  “testable”  so  that  their  achievement  can  be  demonstrated  at  ship 
delivery.  The  review  will  necessarily  involve  the  customer  in  resolving  misunderstandings.  CDD  finalization  and 
submission  to  Navy  staffing  should  follow.  Gate  3  should  proceed  following  the  completion  of  CDD  Navy 
staffing  when  approval  to  enter  Joint  staffing  is  needed. 

The  deliverables  prepared  will  show  greater  detail  than  those  prepared  for  feasibility  studies,  but  will  not  be  up  to 
the  level  of  detail  prepared  for  Preliminary  Design.  They  will  reflect  the  more  in-depth  analyses  performed  as 
part  of  the  design  development  to  demonstrate  the  ship’s  performance.  Design  deliverables  will  include 
engineering  memos,  a  number  of  reports,  and  selected  sketches  and  drawings  (and/or  an  initial  ship  product  model 
(SPM))  with  limited  detail,  primarily  showing  the  feasibility  of  arranging  major  equipments,  validating  the  overall 
adequacy  of  ship  resources  (e.g.,  weight,  space,  power  generation,  cooling,  computer  networks),  and 
demonstrating  that  CDD  performance  can  be  achieved,  particularly  the  KPPs.  A  formal  Pre-Preliminary  Design 
Report  should  be  prepared.  See  Appendix  P  for  a  listing  of  typical  design  deliverables. 

To  help  manage  the  volume  of  information  generated  in  a  typical  ship  design  program,  several  recent  design 
programs,  most  notably  LPD  17  and  DDG1000,  have  maintained  this  data  in  an  SPM  environment.  This  includes 
a  three-dimensional  electronic  representation  of  the  baseline  ship.  It  includes  geometry,  structure, 
compartmentation  and  arrangements,  machinery,  auxiliary  systems  and  components,  C4ISR  and  weapon  systems, 
etc.  As  the  design  evolves  from  initial  concept  through  construction,  delivery,  and,  eventually,  disposal,  the  type 
and  amount  of  information  stored  in  the  product  model  is  ever  increasing.  Specific  design  products  are  extracted 
from  the  product  model  in  electronic  format  to  document  the  design,  trade  studies,  and  analyses,  and  design 
decisions  made  throughout  each  design  phase. 

Depending  upon  the  risk  assessment,  the  SDM  can  recommend  that  parallel  designs  must  be  carried  forward  into 
Preliminary  Design  to  accommodate  alternate  technologies  if  the  ship  impact  is  too  great  to  use  design  budgeting. 
The  review  can  also  conclude  that  a  specific  technology  presents  unacceptable  risks  from  a  technical,  cost,  or 
schedule  standpoint  even  before  a  developmental  program  has  fully  started. 

Although  margin  policies  do  specify  expected  usage,  the  final  design  must  contain  the  full  recommended  margins 
needed  for  subsequent  phases,  regardless  of  usage  during  this  phase.  This  sometimes  requires  resizing  of  the  ship 
before  completing  Pre -Preliminary  Design  in  order  to  accommodate  them.  In  this  regard,  the  more  uncertainty 
that  exists  in  a  particular  design  area  (i.e.,  technical  risk),  the  more  design  detail  and  margins  are  required  at  the 
time  of  the  review. 
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APPENDIX  F 
PRELIMINARY  DESIGN 

Preliminary  Design  is  performed  to  support  a  budget  quality  cost  estimate  and  verify  ship  performance  and 
functionality.  The  requirements  for  the  chosen  baseline  design  and  principal  characteristics  will  be  documented  in 
the  CDD  that  either  should  have  been  approved  or  at  least  be  in  Navy  staffing.  Preliminary  Design  emphasis  is  on 
establishing  ship  size,  external  configuration,  and  the  overall  allocation  of  space  to  various  functions,  major 
propulsion,  electrical,  and  mission  essential  mechanical  and  combat  system  elements.  System  architectures  shall 
be  defined.  Examples  of  essential  mission  systems  would  include  replenishment  systems  on  an  underway 
replenishment  ship,  towing  system  on  a  salvage  (i.e.,  ARS)  ship;  and  aviation,  ship  signature,  C4ISR,  and  weapon 
systems  on  a  combatant  ship.  Changes  in  ship  requirements  initiated  after  this  phase  of  the  ship  design  process 
should  normally  be  incorporated  as  modifications  to  the  existing  baseline,  rather  than  re-optimizing  the  design,  in 
order  to  remain  on  schedule  for  contracting  the  ship. 

Ship  Preliminary  Design  is  typically  6  months  for  single  mission  ships  or  a  modified  repeat  to  12  months  long  for 
a  more  complex  ship,  but  may  be  more  if  a  source  selection  or  down-select  is  involved.  Its  conclusion  is  a 
significant  event  for  the  engineering  evolution  of  a  ship  design. 

Preliminary  Design  will  be  led  by  an  SDM  and  developed  by  a  team  whose  size  will  vary  depending  on  the 
complexity  of  the  design  and  the  degree  of  contractor  support.  A  typical  Preliminary  Design  effort  for  a 
combatant  will  exceed  100  man  years  with  a  Design  Team  of  mostly  part-time  personnel.  A  core  team  of  about  a 
dozen  of  these,  representing  key  functional  areas,  should  be  collocated  to  a  common  work  site.  This  will  enhance 
communication  and  improve  design  efficiency  through  the  many  iterations  of  ship  size  and  configuration 
necessary  in  arriving  at  a  Preliminary  Design  baseline. 

The  collocated  core  team  should  typically  include  the  SDM,  DIM,  PNA,  PME,  a  general  arrangement  engineer, 
structural  engineer,  weight  engineer,  a  SIM,  C4I  integrator,  and  one  or  two  naval  architecture  generalists.  Others 
should  be  included  based  on  the  particular  needs  of  the  program.  If  possible,  including  the  SEMs  in  the  core  team 
is  highly  desirable.  The  core  team  will  interact  continuously  with  the  other  Preliminary  Design  team  members, 
requesting  and  receiving  formal  and  informal  inputs.  A  key  aspect  of  having  the  core  team  co-located,  and 
perhaps  geographically  separated  from  other  Preliminary  Design  team  members,  is  having  integrated  digital 
environment  connectivity  together  with  telephone  and  video  conferencing  support.  Having  a  technical  data 
management  specialist  onboard  to  support  the  core  team  is  highly  desirable.  The  Contract  Design  team  should  be 
assessed  for  its  readiness  to  conduct  the  planned  effort.  Training  for  the  Design  Team  should  be  conducted  prior 
to  the  beginning  of  the  phase  to  include  team  training  and  the  planned  design  process  and  methods. 

The  SIM  is  responsible  for  ensuring  achievement  of  the  safety,  cost,  and  requirements  of  any  associated  weapons 
systems  under  development.  The  SDM  and  SIM  are  also  responsible  for  technical  problems  identification  and 
resolution  within  the  scope  of  their  technical  warrants.  Other  problems  are  referred  to  the  SDM  and  SIM  for 
resolution  by  the  appropriate  TWH.  The  SDM  retains  technical  authority  for  the  total  ship  and  also  normally 
advises  the  program  on  the  resolution  of  technical  issues  and  supports  the  development  of  and  approves  the 
technical  adequacy  of  engineering  changes.  The  SDM  is  responsible  for  managing  the  developing  Functional 
Baseline.  The  SIM  is  responsible  for  the  overall  system  integration  on  the  ship  for  applicable  weapons  systems, 
and  will  assist  the  SDM  for  all  system  integration  issues. 

The  SDM,  DIM,  PNA,  PME,  SIM,  and  C4I  integrator  must  involve  the  designated  TWHs,  as  well  as 
representatives  of  other  Navy  Systems  Commands,  ABS,  and  other  government  activities,  in  Preliminary  Design 
planning.  Tasks,  products,  schedules,  and  costs  for  design  support  must  be  negotiated  and  documented.  Each 
TWH  is  responsible  for  the  technical  integrity  of  that  portion  of  the  design  over  which  it  has  cognizance. 
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Current  NAVSEA  staffing  levels  dictate  that  the  majority  of  the  Design  Team  will  come  from  outside  sources 
such  as  NSWC  Carderock,  Philadelphia,  or  Dahlgren,  or  from  contractors.  Depending  upon  the  acquisition 
strategy,  the  design  will  either  be  a  government  controlled  one  where  the  NAVSEA  SDM  controls  the  design  and 
makes  the  design  decisions.  Or  it  may  be  a  contractor  controlled  design,  where  a  contractor  team  prepares  it  and 
makes  the  design  decisions  except  for  any  “fenced  areas”  over  which  NAVSEA  maintains  control.  In  the  latter 
case,  the  role  of  the  NAVSEA  Design  Team,  including  the  SDM,  is  to  review  and  monitor  the  design  and  to 
identify  areas  where  it  might  be  technically  deficient  or  not  compliant  with  the  requirements.  The  PEO  and  the 
Contracting  Officer  must  review  technical  direction  from  the  NAVSEA  Design  Team  in  this  type  of  design, 
because  in  many  cases  it  will  change  the  terms  of  the  design  contract. 

To  ensure  it  remains  focused  on  the  overall  program  objectives,  members  must  avoid  conflicts  of  interest  or  the 
appearance  of  a  conflicts  within  their  parent  organizations.  Often,  individual  members  of  the  Design  Team  are 
required  to  sign  a  non-disclosure/conflict  of  interest  agreement  as  a  condition  of  participation  in  the  design  effort. 

It  may  also  be  possible  that  the  acquisition  strategy  calls  for  the  conduct  of  Contractor  Designs.  In  this  case  SDM 
will  be  responsible  for  supporting  the  development  of  the  RFP  and  subsequent  source  selection.  Although  a 
contractor  may  perform  the  Preliminary  Design,  responsibility  for  the  technical  adequacy  of  the  construction 
specifications,  contract  drawings,  and  PPDs,  etc.  always  remains  with  the  government  SDM. 

Design  efforts  should  be  preceded  by  development  and  approval  of  a  Preliminary  Design  Engineering 
Management  Plan  and  study  guide(s).  Event-based  design  reviews  should  be  scheduled  at  the  peer  level  including 
participation  by  the  prospective  Program  Office,  OPNAV  Sponsor,  TWHs,  other  supporting  technical  codes,  and 
other  stakeholders. 

Preliminary  Design  should  conclude  with  a  System  Functional  Review  (SFR)  (SETR  for  the  Functional  Baseline) 
in  conjunction  with  a  TRB  and  SSB  when  sufficient  design  maturity  is  achieved  to  establish  a  Functional 
Baseline.  If  technical  feasibility  has  not  been  demonstrated  in  the  broad  sense,  or  if  a  stable  Functional  Baseline 
has  not  been  achieved,  the  conduct  of  SFR  should  be  delayed.  The  entire  SFR  process  can  take  a  substantial 
amount  of  time.  A  series  of  lower  level  reviews  should  be  conducted  over  the  course  of  the  Preliminary  Design 
leading  to  a  final  review  which  itself  may  be  conducted  in  multiple  sessions.  In  very  complex  programs  with  a 
high  degree  of  concurrency  for  system  developments,  the  whole  process  can  last  months.  On  the  plus  side,  the 
benefits  of  such  a  long  process  are  the  discovery  of  issues  early  enough  in  the  phase  to  influence  the  design  prior 
to  the  final  review.  However,  a  significant  planning  effort  to  successfully  execute  this  cascade  of  reviews  and 
planning  should  be  initiated  early  in  the  phase.  Outside  reviews  started  in  Pre -Preliminary  Design  and  Fleet 
interface  activities  should  be  expanded. 

SDS  development  and  CDD  approval  should  normally  proceed  in  parallel  to  support  SDS  approval  and  Gate  4 
conduct  as  soon  as  possible  after  CDD  approval.  This  proves  a  firm,  timely  basis  to  begin  or  even  finalize  the 
System  Specification  in  Preliminary  Design.  This  is  essential  for  early  finalization  of  the  System  Specification 
for  conduct  of  contractor  Preliminary  and/or  Contract  Designs.  Gate  5  ensures  that  the  Program  has  completed 
needed  actions  and  recommends  to  the  MDA  approval  of  the  release  of  the  RFP  to  industry  as  authorized  by  the 
Acquisition  Strategy.  Gate  5  scheduling  is  highly  dependent  on  the  Program’s  acquisition  strategy.  For  a 
contractor  Preliminary  and/or  Contract  Design  Gate  5  conduct  should  also  be  accelerated. 

The  principle  product  of  this  phase  is  the  Preliminary  Design  Report.  This  is  a  comprehensive  description  of  the 
characteristics  and  capabilities  of  the  ship  at  the  end  of  the  design  phase.  It  describes  how  the  ship  meets  the 
requirements  contained  in  the  CDD  and  the  significant  trade  studies  performed,  with  the  supporting  rationale  for 
selections  made.  Many  drawings,  studies,  tests,  and  analyses  are  developed  to  support  the  preparation  of  the 
design  report  and  the  Preliminary  Design  Report.  They  can  easily  number  in  the  hundreds  of  documents.  A 
typical  set  of  supporting  documents,  taken  from  the  standard  SOWs,  is  shown  in  Appendix  P.  Not  all  of  these 
documents  will  be  required  for  each  program. 
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The  Design  Certification  Matrix  is  an  important  document  that  is  developed  early  in  Preliminary  Design.  It  is 
finalized  for  inclusion  in  the  RFP,  and  updated  as  appropriate  during  later  stages  of  design  if  necessary  and 
depending  on  the  contracting  approach.  As  a  contract  item,  it  will  be  under  formal  configuration  control.  The 
Design  Certification  Matrix  documents  which  organizational  entity  is  the  technical  lead  forjudging  the 
contractor’s  design  (and  finished  product)  to  be  in  compliance  with  the  requirements,  and  resolving  any 
associated  issues.  The  technical  entity  with  that  responsibility  is  called  the  “Certification  Authority”. 

Certification  authority  is  not  the  same  as  technical  authority.  The  Navy,  acting  through  the  SDM,  SIM,  and 
accountable  TWHs,  always  retains  technical  authority.  The  requirement  for  the  government  to  exercise  technical 
authority  is  based  in  statute  and  cannot  be  delegated  to  industry  or  other  entities.  If  the  Certification  Authority  is 
outside  of  NAVSEA,  the  Navy  will,  in  the  preponderance  of  instances,  defer  to  the  Certification  Authority  in 
judgments  about  compliance.  But  the  SDM  must  stay  fully  engaged  in  that  process.  Using  a  risk-based  spot 
checking  approach,  the  SDM  may  disagree  with  the  Certification  Authority.  In  those  typically  very  limited 
number  of  cases,  the  SDM  will  then  elevate  the  issue  as  appropriate,  working  with  a  diligent  sense  of  urgency 
toward  resolution  in  order  to  minimize  impact  on  the  contractor.  Other  Certification  Authorities  should 
participate  in  design  reviews/problem  solving  groups  as  necessary. 

Preliminary  Design  should  see  the  active  execution  of  approved  risk  mitigation  plans.  By  the  conclusion  of  the 
phase,  all  risks  should  have  been  mitigated  to  medium  or  low  (preferred),  be  advancing  on  schedule,  and  be  in 
keeping  with  ship  resource  limits  of  weight,  space,  power,  etc.  Space  and  weight  budgets  for  fallbacks  can  be 
considered  for  elimination  if  the  new  technology  has  achieved  “low”  risk  by  the  end  of  the  phase,  which  may  help 
in  margin  availability  for  the  rest  of  the  design.  Similarly,  if  parallel  designs  have  been  maintained,  a  “down 
select”  should  occur  as  early  in  the  phase  as  practical,  based  on  pre-agreed  success  criteria,  usually  involving 
testing. 

By  the  SFR,  the  production  schedules  for  the  ship  and  for  the  new  technologies  should  be  known  and  their 
acceptability  determined.  Schedule  alone  may  force  the  decision  to  postpone  the  technology  to  a  later  flight  of  the 
ship  class.  A  thorough  review  of  risk  mitigation  activities  is  an  essential  prerequisite  to  a  satisfactory  SFR. 

As  previously  noted,  design  margins  should  be  being  consumed  at  the  planned  rate  during  this  phase.  Farge 
deviation  from  the  plan  is  a  good  indicator  of  design  immaturity  and  inherent  risks.  If  needed,  special  “weight 
reduction”  efforts,  etc.  should  be  employed  to  get  back  to  the  planned  expenditure  rate.  The  SFR  should  not 
conclude  unless  adequate  margins  are  available  for  subsequent  design  phases. 

As  the  Preliminary  Design  is  wrapping  up,  it  is  important  to  begin  preparations  for  the  start  of  Contract  Design  so 
that  the  transition  happens  seamlessly  in  a  timely  manner.  Planning  should  be  reviewed  and  updated  to  reflect  the 
latest  acquisition  strategy  for  the  program  and  specifically  the  latest  plans  for  Contract  Design,  including 
schedule,  participants,  and  key  decisions.  By  the  end  of  Preliminary  Design  the  initial  Contract  Design 
Engineering  Management  Plan  and  associated  study  guides  must  be  completed.  Further,  they  should  be  approved 
prior  to  the  start  of  Contract  Design.  The  SDM  is  responsible  for  ensuring  the  content  of  the  Contract  Design 
Engineering  Management  Plan  is  consistent  with  the  SEP  issued  by  the  Program  Office.  Scheduling  and  funding 
of  events  must  agree  with  the  PEO  acquisition  strategy  and  the  OPNAV  budget  line.  The  SDM  must  work 
closely  with  the  OPNAV  Sponsor  and  the  Program  Manager  to  ensure  that  the  plans  for  Contract  Design  are  in 
agreement. 
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APPENDIX  G 
CONTRACT  DESIGN 

Contract  Design  translates  the  engineering  findings  and  decisions  from  Preliminary  Design  into  a  biddable 
technical  package.  It  provides  a  design  baseline  budget  quality  cost  estimate  suitable  for  Milestone  B  review. 
There  is  a  general  validation  of  the  Functional  Baseline  developed  in  Preliminary  Design  through  increased  levels 
of  system/subsystem  definition  to  create  an  Allocated  Baseline. 

This  “bid  package”  includes  a  Ship  Specification,  Contract  Drawings,  ABS  approval  requirements  (as  applicable), 
DRL,  PPDs,  GFE  and  GFI  lists,  and  the  contracts.  Other  important  products  of  this  phase,  which  are  not  part  of 
the  contract  package,  are  study  drawings,  study  reports,  Engineering  Management  Plan,  Contract  Design  History, 
and  a  Contract  Design  Report.  See  Appendix  P.  The  end  result  of  Contract  Design  is  a  technical  package  that 
will  enable  bids  for  the  construction  of  the  ship.  The  technical  portion  of  the  phase  concludes  with  design 
approval  by  the  TWHs  as  manifested  by  signing  of  the  Ship  Specifications  and  associated  Contract  Drawings. 

Ship  Contract  Design  is  typically  12  months  for  single  mission  ships  or  a  modified  repeat  to  24  months  long  for  a 
more  complex  ship,  but  may  be  more  if  a  source  selection  or  down-select  is  involved.  Its  conclusion  is  a 
significant  event  for  the  engineering  evolution  of  a  ship  design. 

During  Contract  Design,  the  Design  Team  will  typically  evolve  from  the  Preliminary  Design  team  with  additional 
resources  added  to  address  the  increased  workload  and  technical  disciplines  associated  with  development  of  the 
Ship  Specification,  Contract  Drawings,  and  other  deliverables.  A  typical  Contract  Design  effort  for  a  combatant 
ship  will  consist  of  about  200  man  years  using  mostly  part-time  personnel,  with  a  nucleus  or  core  group  of  18-24 
individuals  collocated  at  a  common  worksite.  This  core  group  will  serve  as  the  “integration”  team  to  steer  the 
design,  identify  required  trade  studies,  maintain  configuration  documents  such  as  the  general  arrangements,  and 
pull  resources  from  the  available  government  or  contractor  technical  pool.  This  will  enhance  communications  and 
improve  design  efficiency  through  the  many  iterations  of  ship  configuration  necessary  to  arrive  at  an  optimized 
design  solution.  The  Contract  Design  team  should  be  assessed  for  its  readiness  to  conduct  the  planned  effort. 
Training  should  include  team  training  and  training  in  planned  design  processes  and  methods. 

The  collocated  core  group  should  include  the  SDM,  DIM,  PNA,  PME,  Specifications  Manager,  and  TWHs  from 
general  arrangements,  weights  and  stability,  structures,  propulsion  systems,  electrical  systems,  SIM,  C4I 
integration,  HVAC  systems,  fluid  systems,  mechanical  and  deck  systems,  and  HSI.  The  core  team  should  also 
include  two  or  three  general  naval  architects.  A  small  support  staff  should  also  be  included  to  monitor  and  track 
products  and  deliverables  and  coordinate  meetings,  briefings,  and  other  team  activities.  For  combatant  ships,  the 
core  team  should  include  a  survivability  specialist  to  coordinate  the  various  studies  and  analyses  related  to 
susceptibility,  vulnerability,  and  recoverability.  If  possible,  having  the  SEMs  included  in  the  core  team  is  highly 
desirable.  Core  team  members  will  interface  with  their  SEM  counterparts  to  coordinate  design  efforts  across  the 
organization. 

It  may  also  be  possible  that  the  acquisition  strategy  calls  for  the  conduct  of  Contractor  Designs.  In  this  case  SDM 
will  be  responsible  for  supporting  the  development  of  the  RFP  and  subsequent  source  selection.  Although  a 
contractor  may  perform  the  Contract  Design,  responsibility  for  the  technical  adequacy  of  the  construction 
specifications,  contract  drawings,  and  PPDs,  etc.  always  remains  with  the  government  SDM. 
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Once  a  program  reaches  Contract  Design,  the  maturity  of  the  design  is  such  that  a  firm  Functional  Baseline  has 
been  achieved  and  no  significant  changes  in  the  principal  characteristics  is  expected.  As  such,  during  Contract 
Design  the  primary  focus  of  the  Design  Team  shifts  from  design  development  to  the  development  of  the  contract 
documentation  which  describes  an  Allocated  Baseline.  There  is  particular  emphasis  on  development  of  a  Ship 
Specification  that  can  be  used  as  the  basis  to  award  ship  Detail  Design  and  Construction.  See  NAVSEA 
Technical  Standards  Procedures  and  NAVSEA  Instruction  4121. 3A  (hyperlink).  All  systems  will  have  been 
diagrammed;  all  design  trades  completed;  space  arrangements  showing  all  compartmentation,  accesses,  and 
significant  equipments  will  exist;  all  risks  will  have  been  reduced  to  “low”  (unless  planned  to  be  otherwise);  and  a 
Specification  or  set  of  specifications  will  exist.  A  SPM  should  exist  and,  if  so,  should  be  the  basis  for  design 
development  and  reviews.  The  design  will  be  ready  for  transition  to  Shipbuilder  production  personnel  who  will 
develop  the  Detail  Design  and  fully  refine  construction  planning. 

Lessons  Learned  from  recent  ship  construction  programs  has  shown  that  the  government  should  maintain 
configuration  control  of  the  development  of  the  contract  documentation.  Shipbuilder  developed  Ship 
Specifications  have  not  resulted  in  delivered  ships  fully  meeting  government  expectations  and  have  not  generally 
benefitted  from  lessons  learned  on  other  ship  acquisition  programs. 

The  development  of  the  Ship  Specification,  Contract  Drawings,  and  other  design  products  continues  throughout 
the  entire  Contract  Design.  During  this  effort  minor  design  changes  may  occur  as  analysis  is  performed  to  verify 
the  feasibility  of  the  Ship  Specifications  and  drawings.  This  analysis  may  include  the  development  of  system 
level  diagrams  and  calculations.  Although  a  Detail  Design  is  not  performed  for  each  system  during  Contract 
Design  it  is  important  that  the  appropriate  level  of  verification  is  performed  to  ensure  the  design  documented  in 
the  specifications  and  drawings  is  feasible.  The  appropriate  level  of  verification  will  vary  from  program  to 
program  based  on  several  factors  such  as  whether  the  design  is  a  clean  sheet  or  a  modified  repeat  of  an  existing 
ship.  If  it  is  a  modified  repeat  the  amount  of  analysis  necessary  to  verify  the  feasibility  of  the  requirements  may 
be  limited  to  only  those  areas  where  the  design  has  been  changed.  A  determination  of  how  much  analysis  should 
be  performed  will  be  decided  by  the  system  technical  lead  and  the  SDM. 

The  development  of  contract  documentation  (Ship  Specification,  Contract  Drawings,  PPDs,  and  DRL)  may  be 
accomplished  using  several  different  approaches.  In  general,  the  task  and  level  of  effort  to  develop  this 
documentation  can  be  significantly  reduced  if  a  parent  ship  with  similar  system  requirements  can  be  identified.  If 
so,  specific  Ship  Specification  sections  and  possibly  drawings  can  be  used  as  an  initial  baseline  and  modified  to 
suit  the  specific  requirements  and  ship  configuration  changes  of  the  design.  If  a  parent  can  not  be  identified,  the 
contract  documentation  must  be  developed  from  a  clean  sheet  approach.  With  this  approach  the  specific  Ship 
Specification  sections  are  prepared  using  design  standards  and  criteria  from  documents  such  as  Naval  Vessel 
Rules,  Design  Data  Sheets,  and  Design  Criteria  Manuals.  The  General  Specifications  for  Overhaul  should  also  be 
reviewed.  These  documents  form  the  basis  of  the  current  design  standards  and  are  tailored  to  suit  specific  design 
requirements.  Either  method  is  an  acceptable  approach  for  developing  a  Ship  Specification  however  since  these 
documents  do  not  necessarily  conform  to  the  format  requirements  of  a  Ship  Specification  the  author  must  ensure 
compliance  with  appropriate  specifications  writing  format  and  protocol.  These  documents  form  the  basis  of  the 
current  design  standard  and  are  then  tailored  to  suit  the  specific  design  requirements.  Either  method  is  an 
acceptable  approach  to  developing  contract  documentation. 
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The  development  of  contract  documentation  is  an  iterative  effort  and  continues  through  Contract  Design.  Since  it 
is  an  iterative  process  it  is  necessary  for  the  SDM  to  implement  a  rigorous  and  formal  configuration  management 
process.  The  process  must  be  documented  in  the  Specification  Management  Plan  and  fully  understood  by  the 
entire  Design  Team.  An  effective  configuration  management  process  documents  change,  tracks  reviews, 
documents  approvals,  and  traces  requirements.  Since  ship  design  is  a  multi-disciplinary  iterative  process  it  is 
imperative  that  changes  are  initiated,  reviewed,  and  ultimately  approved  through  a  process  that  will  ensure  all 
secondary  and  tertiary  impacts  are  identified  and  resolved.  The  contract  documentation,  particularly  the 
specifications,  should  be  managed  in  a  requirements  traceability  program  such  as  DOORS©.  Traceability  is  an 
important  aspect  of  configuration  management  and  ensures  that  proposed  changes  can  be  verified  or  traced  to  a 
specific  requirement.  Without  a  formal  requirements  traceability  process  it  is  not  possible  to  ensure  the  current 
design  and  proposed  changes  meet  and  not  exceed  the  threshold  requirements. 

Particular  attention  should  be  placed  on  the  DRL.  The  required  content  of  every  document  provided  to  the 
government  should  be  unambiguous.  The  required  delivery  date  of  the  deliverables  must  also  be  carefully  defined 
to  avoid  having  “shell”  documents  submitted  by  the  contractor  to  meet  the  delivery  schedule  but  devoid  of  the 
required  content. 

In  defining  GFE,  GFI,  and  Government  Property,  the  contract  should  be  unambiguous  as  to  the  identification  and 
planned  use  for  design,  construction,  and/or  testing. 

Lessons  Learned  from  recent  ship  construction  programs  have  shown  that  because  of  the  impact  of  software 
development  on  cost  and  schedule,  development  of  Software  Configuration  Items  should  generally  complete 
before  the  end  of  Contract  Design.  Software  Integration  in  Detail  Design  is  acceptable.  Any  software 
development  planned  for  Detail  Design  should  be  tracked  as  a  program  risk. 

Design  efforts  should  be  preceded  by  development  and  approval  of  a  Contract  Design  Engineering  Management 
Plan  and  study  guide(s).  Event-based  design  reviews  should  be  scheduled  at  the  peer  level  including  participation 
by  the  prospective  Program  Office,  OPNAV  Sponsor,  TWHs,  other  supporting  technical  codes,  and  other 
stakeholders.  If  Gate  4  wasn’t  conducted  during  Preliminary  Design,  it  will  need  to  be  conducted  as  soon  as 
possible  during  Contract  Design  so  the  SDS  can  be  approved  as  a  basis  for  System  Specification  development. 

The  SDM  will  also  be  required  to  provide  input  to  the  Gate  5  which  will  approve  the  RFP. 

Contract  Design  should  conclude  with  a  Preliminary  Design  Review  (SETR  for  the  Allocated  Baseline)  in 
conjunction  with  a  TRB  and  SSB.  The  PDR  requires  extensive  preparatory  work,  similar  to  the  SFR,  but  this 
time  focused  primarily  on  the  Ship  Specifications  and  contract  drawing  package.  The  heart  of  this  effort  is  called, 
“spec  reading  sessions,”  during  which  a  myriad  of  ship  integration  details  are  finalized.  It  is  an  extremely  time- 
consuming  and  arduous  function  performed  over  a  period  of  months  and  must  be  done  in  a  close  working 
relationship  with  the  Program  Office  with  strong  participation  by  the  technical  authorities  and  ABS  as  applicable. 
Numerous  additional  reviews  are  conducted  throughout  the  phase  as  indicated  below  in  the  entrance  criteria 
section.  If  the  vessel  is  to  be  ABS  classed,  ABS  should  have  been  asked  to  conduct  a  design  review  of  all 
artifacts  that  relate  to  the  appropriate  Rule  set.  A  Contract  Design  Assessment  letter  shall  be  sent  signifying  that 
no  “fatal  flaws”  exist  which  will  preclude  the  vessel  ultimately  receiving  ABS  classification.  Again,  careful 
planning  for  this  review  should  start  early  in  the  phase. 

The  Engineering  Management  Plan  will  indicate  who  will  review  and  approve  each  design  product.  The  TWHs 
will  normally  review  and  approve  the  Ship  Specifications  and  Contract  Drawings.  Other  drawings  and  contract 
documents  will  be  reviewed  and  approved  by  the  SDM.  The  Program  Office  may  have  special  preferences  for 
additional  reviews  and  approvals  that  must  be  considered.  The  SDM  will  ensure  that  certification  sheets  have 
been  approved  for  each  Ship  Specification  section.  Requirements  traceability  will  be  employed  to  ensure  that  all 
CDD  requirements  are  adequately  covered  in  the  Ship  Specifications.  The  SDM  will  certify  that  the  coverage  is 
complete  and  the  quality  of  the  design  package  is  adequate. 
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APPENDIX  H 
SOURCE  SELECTION 

For  a  Contractor  Design,  the  Program  Officer  and  the  Contract  Directorate  may  develop  and  issue  an  RFP  or 
equivalent  document  for  Preliminary  and/or  Contract  Design  followed  by  a  down  selection  for  Detail  Design  or 
issuance  of  a  new  RFP.  For  a  Navy  Design,  the  RFP  would  be  issued  for  DD&C.  Although  this  is  the  prime 
responsibility  of  the  Program  Office  and  the  Contract  Directorate,  the  SDM,  SIM,  and  Design  Team  are  involved 
to  ensure  that  it  addresses  the  technical  issues  and  references  the  appropriate  specifications,  drawings,  data 
requirements,  and  other  appropriate  documents. 

The  first  step  in  the  source  selection  process  is  preparation  of  the  RFP.  The  SDM  will  be  responsible  for 
preparing  input  to  the  SOW,  describing  all  of  the  ship  design  efforts  required  of  the  Shipbuilder  during  DD&C. 

In  addition,  the  SDM  will  coordinate  development  of  the  list  of  technical  DRLs  which  will  include  all  of  the 
technical  deliverables  that  will  be  submitted  by  the  Shipbuilder  during  DD&C.  The  SDM  will  also  coordinate 
development  of  the  schedule  for  technical  deliverable  submittal,  and  the  government  review  and  approval 
required. 

Ships  and  their  systems  and  equipment  are  defined  by,  and  their  performance  is  directly  related  to,  the  technical 
documentation  generated  for  their  design,  production,  installation,  test,  and  follow-on  in-service  operation  and 
support.  The  identification  and  control  of  key  technical  documentation  is  fundamental  to  ensuring  sound  and 
sustainable  products  are  delivered  to  the  Fleet.  Particular  attention  must  be  given  to  documentation  related  to 
those  systems  and  equipment  that  are  critical  to  the  ship’s  mission,  survivability,  and  safety.  Collectively,  these 
systems,  equipments,  and  attributes  are  hereafter  referred  to  as,  “critical  ship  elements.” 

It  is  the  policy  of  NAVSEA  that  headquarters  control  is  exercised  over  technical  documentation  developed  for 
critical  ship  elements  during  the  ship  acquisition  process.  DRL  deliverables  are  designated  as  one  of  three  levels 
of  technical  control:  approval,  review,  or  receipt.  These  levels  are  defined  as  follows: 

•  Approval  indicates  that  written  approval  by  a  government  representative  is  required  prior  to  final 
acceptance  by  the  government,  prior  to  publication  and  distribution  of  final  revisions  of  the  item  or 
prior  to  some  action  defined  in  the  SOW  or  Specification.  Only  the  Program  Office  will  approve  DRL 
deliverables  requiring  NAVSEA  headquarters  approval.  The  Design  Team  will  conduct  a  detailed 
technical  review  of  DRL  items  requiring  approval.  The  Design  Team  will  prepare  the  approving  (or 
disapproving)  letter  for  Program  Office  release  or  will  furnish  detailed  comments  for  inclusion  in 
Program  Office  correspondence. 

•  Review  indicates  that  the  Design  Team  will  subject  the  DRL  deliverable  to  a  positive  technical  review 
to  ensure  compliance  with  contract  Specifications.  Items  designated  for  review  do  not  require  formal 
approval  action  by  the  government.  Flowever,  the  Design  Team  will  certify  in  writing  to  the  Program 
Office  that  the  DRL  deliverable  has  been  reviewed  and  either  meets  or  does  not  meet  contract 
Specifications.  In  the  latter  case,  a  letter  will  be  prepared  for  the  Program  Office’s  release,  identifying 
where  the  deliverable  does  not  conform  to  specifications  or  the  design  as  described  in  the  deliverable 
does  not  conform  to  the  specification  and  requiring  corrective  action  by  the  contractor. 

•  Receipt  indicates  the  DRL  deliverable  will  not  be  subjected  to  any  specific  technical  review,  but  is 
needed  by  the  government  for  information  or  reference  purposes.  In  general  to  avoid  needless  DRL 
preparation  cost,  this  type  of  DRL  should  be  avoided.  Instead  the  SOW  should  contain  a  requirement 
for  electronic  access  to  such  data  on  a  shared  IDE  with  periodic  updates. 

The  approval  level  of  control  imposes  responsibility  and  accountability  on  the  Design  Team  for  the  accuracy, 
adequacy,  and  completeness  of  the  DRL  item  itself,  as  well  as  performance  of  the  end  item.  It  carries  with  it  the 
contractual  risk  of  potential  delay  and,  to  some  extent,  shifts  the  burden  of  responsibility  for  satisfactory 
performance  of  the  end  item  from  the  contractor  to  the  government.  It  is  imperative  that  the  SDM  and  TWHs  be 
sensitive  to  this  potential  liability  and  ensure  the  necessary  resources  are  identified  and  committed  to  insure 
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thorough  technical  review  and  timely  response  on  a  priority  basis.  Consideration  should  be  given  to 
implementing  a  “paperless”  process  for  review  and  approval  of  design  documentation. 

The  SDM  will  also  support  the  Program  Office  and  the  Contracting  Officer  in  providing  specific  technical  input 
to  other  aspects  of  the  RFP  development. 

After  release  of  the  RFP  to  prospective  bidders,  but  prior  to  award  of  the  contract,  bidders  submit  questions, 
requests  for  clarification,  and  recommended  changes.  The  Program  Office  responds  to  these  items  in  writing. 

The  SDM  will  coordinate  the  TWH  responses  to  technical  bidders’  questions  for  forwarding  to  the  Program 
Office.  If  necessary,  the  SDM  will  also  prepare  and  submit  to  the  Program  Office  modifications  to  the  contract 
package,  generally  in  the  form  of  modification  pages  to  the  Specifications  and  DRL  and  drawing  revisions. 

Once  the  proposals  have  been  received  from  the  bidders,  the  SDM  will  be  responsible  for  the  technical  review  of 
the  proposals.  The  SDM  will  establish  a  Technical  Evaluation  Review  Panel  from  the  Design  Team  to  review  the 
portions  of  the  proposal  in  their  technical  areas.  The  SDM  must  ensure  that  all  technical  areas  are  covered  by  the 
panel  so  that  a  complete  evaluation  can  be  made. 

The  SDM  will  be  responsible  for  collecting  and  compiling  all  of  the  results  from  the  technical  evaluation  and 
providing  these  results  and  scoring  to  the  contracting  officer  and  source  selection  team. 

Following  the  contract  award,  the  SDM  will  participate  in  any  debriefs  to  the  bidders. 
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APPENDIX  I 

DETAIL  DESIGN  AND  CONSTRUCTION 

During  Contract  Design,  emphasis  was  placed  on  development  of  a  firm  technical  baseline  to  support  Shipbuilder 
proposals  to  perform  DD&C  of  the  ship.  Detail  Design  is  the  production  of  all  design  and  engineering 
deliverables  required  to  construct,  test,  and  certify  the  ship.  Note  that  Detail  Design  is  often  broken  into  phases. 
The  most  commonly  used  terminology  is  for  Detail  Design  to  begin  with  “Functional  Design”  and  then  proceed  to 
“Transitional  Design.” 

With  the  possible  exception  of  a  new  combat  system,  all  systems  will  have  been  designed,  built,  and  tested;  unless 
the  ship  is  a  “demonstrator”  or  developmental  prototype,  all  risks  will  have  been  reduced  to  “virtually  zero”  or 
have  an  accepted  mitigation  plan.  In  the  event  that  there  are  technologies  involving  risk  (e.g.,  new  composite 
deckhouse),  by  the  time  of  the  first  design  review  or  Ship  Production  Progress  Conference  (SPPC),  any  risk 
mitigation  plans  should  be  executing  on  schedule.  When  a  technology  in  this  category  not  meeting  these  criteria 
is  applied,  it  is  best  to  have  a  fallback  option  completely  detailed  to  the  Contract  Design  level  of  definition  and  a 
“design  budget”  that  will  permit  the  new  technology  to  be  installed  at  the  proper  time  if  it  completes  development 
successfully.  In  some  cases,  the  fallback  option  may  be  reflected  as  the  baseline  in  the  contract  package  (e.g., 
insertion  of  Advanced  Enclosed  Mast/Sensor  System  (AEM/S)  on  LPD  17).  Firm  off-ramp  and  decision  dates 
should  be  established  early  in  the  phase  for  any  such  items. 

The  ship  will  be  delivered,  and  all  DRL  items  dealing  with  design,  testing,  technical  documentation,  provisioning, 
and  training  will  be  completed.  Changes  resulting  from  combat  system  land-based  test  sites  and  operational 
testing  and  engineering  changes  are  incorporated  in-stride,  and  the  ship  and  engineering  deliverables  are  modified 
as  appropriate. 

Use  of  design  margins  should  be  as  planned  with  the  full  allowance  available  for  DD&C  and  agreed  service  life 
allowances  available  at  delivery.  At  this  point,  significant  design  changes  are  almost  impossible  due  to  the 
schedule.  One  of  the  few  options  available  to  recoup  margins  is  to  eliminate  redundancies  or  even  whole  systems. 
Such  decisions  should  follow  the  design  philosophy  and  retain  as  many  of  the  CDD  capabilities  as  possible. 

Upon  award  of  the  contract,  lead  ship  DD&C  will  be  performed  almost  entirely  by  the  Shipbuilder,  with 
NAVSEA  headquarters  retaining  technical  control  over  critical  ship  elements,  such  as  key  mission  systems.  This 
may  be  a  shift  in  design  responsibility  from  a  government  Design  Team  with  contractor  support  during  the 
previous  design  stages,  depending  upon  the  acquisition  strategy.  If,  however,  it  has  been  a  Contractor  Design 
with  government  oversight  there  will  be  little  or  no  change  in  responsibility. 

Ship  Detail  Design  durations  can  range  from  as  low  as  12  months  for  single  mission  ships  or  a  modified  repeat  to 
36  months  or  even  longer  for  a  more  complex  ship.  Detail  Design  should  largely  complete  prior  to  the  start  of 
lead  ship  construction  to  avoid  expensive  rework. 
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The  Design  Team  will  normally  evolve  with  relatively  few  changes  in  positions  but  significant  adjustments  in 
assigned  workload  from  the  organization  employed  during  Contract  Design.  The  emphasis  will  shift  to  review  of 
Shipbuilder  Detail  Design  deliverables  and  monitoring  and  control  of  action  items,  Request  for  Clarification, 
Information,  and  Assistance  (RCIAs),  and  Engineering  Change  Proposals  (ECPs).  The  SDM  should  work  with 
the  SEMs  to  ensure  resources  are  in  place  to  support  the  review  of  design  products/deliverables  as  they  are 
received  from  the  Shipbuilder.  The  Shipbuilder’s  integrated  master  schedule,  along  with  the  DRL  schedule,  can 
be  used  as  a  guide  to  assist  in  planning  for  this  effort.  The  timely  return  of  comments  and  approvals  of  these 
drawings  and  other  documents  is  critical  to  prevent  Shipbuilder  delay  claims.  If  a  field  activity  or  contractor  will 
perform  the  detail  review,  this  must  be  scheduled  and  funded.  The  total  number  of  manhours  required  may  or 
may  not  significantly  decrease  from  Contract  to  Detail  Design  depending  on  the  acquisition  strategy  and  schedule. 
Roles  and  responsibilities  should  be  clearly  defined  during  final  stages  of  Contract  Design  and  documented  in  the 
Detail  Design  EMP.  Where  supporting  field  activities  or  contractors  are  required  to  participate,  arrangements 
must  be  made  two  or  three  months  in  advance  of  contract  award  to  have  these  activities  ready  to  start  their  work 
as  needed.  Periodic  review  of  the  support  team  structure  will  ensure  an  effective  and  active  organization.  The 
Detail  Design  team  should  be  assessed  for  its  readiness  to  conduct  the  planned  effort.  Training  should  include 
team  training  and  training  in  planned  design  processes  and  methods. 

SUPSHIP  is  a  key  player  in  DD&C  and  as  such  the  SDM  must  quickly  establish  a  good  working  relationship  with 
them.  Because  they  have  not  traditionally  been  involved  in  the  design  until  this  phase,  this  is  a  new  relationship 
that  must  be  established.  SUPSHIP  serves  as  the  on-site  technical  representative  for  the  Navy  where  they  will 
make  many  technical  decisions  regarding  the  design  and  construction  of  the  ship.  The  SDM  must  work  with  the 
SUPSHIP  to  establish  bounds  on  their  authority  and  ensure  that  all  parties  clearly  understand  their  roles.  Clearly 
defining  under  what  circumstances  SUPSHIP  can  make  autonomous  decisions  and  when  to  involve  the  SDM  and 
the  Design  Team  must  occur  at  the  start  of  DD&C.  Ultimately,  the  SDM  must  have  a  close  relationship  with 
SUPSHIP,  so  that  they  understand  and  trust  each  other’s  judgment,  with  the  roles  clearly  defined.  The 
relationships  should  be  defined  in  the  Engineering  Management  Plan.  See  NAVSEAINST  5400.95E  (hyperlink). 

Should  the  requirement  exist  that  the  T-ship  be  ABS  classed,  ABS  will  function  as  an  independent  agent  to  review 
and  approve  drawings  as  required  by  the  defined  Rule  set  and  to  provide  surveyor  attendance  during  construction 
to  assess  compliance  of  the  ship  with  the  defined  Rule  set.  See  Appendix  T. 

The  split  in  responsibility  between  the  SDM  and  the  SUPSHIP  Office  and  the  relationship  of  ABS  is  documented 
in  the  Engineering  Management  Plan.  Typically,  the  SDM  will  retain  responsibility  for  new  and  high-risk 
systems  while  SUPSHIP  will  take  responsibility  for  low-risk  systems. 

The  Program  Office  will  implement  configuration  management  and  establish  a  Configuration  Control  Board  for 
the  ship  contractual  baseline.  The  SDM  and  associated  SIM  as  members  of  the  Board,  are  responsible  for 
coordinating  the  review  of  all  ECPs  prepared  by  the  Shipbuilder  or  other  activities  outside  NAVSEA.  The  SDM 
must  develop  procedures  for  handling  ECPs  and  for  preparing  them  to  cover  subjects  required  by  the  Program 
Office.  These  procedures  will  be  documented  in  the  Engineering  Management  Plan.  Specific  guidance  for 
implementation  of  Configuration  Management  is  provided  in  NAVSEAINST  4130. 12B,  Configuration 
Management  (hyperlink).  See  also  Appendix  U  (hyperlink). 

The  topic  of  performing  Detail  Design  reviews  in  an  integrated  digital  environment  is  discussed  in  recent 
technical  papers.  Centralizing  information  and  de -centralizing  model  review  capability  has  increased  stakeholder 
involvement.  The  true  value  of  employing  integrated  digital  environments  for  review  will  be  determined  as 
DDG-1000  and  other  recent  ship  programs  deploy  their  first  ships. 
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A  Quick  Circuit  Technical  Resolution  Process  common  to  the  Shipbuilder  and  the  government  can  expedite  the 
resolution  of  emergent  issues  that  have  “immediate  and  significant”  impact  to  a  critical  path,  key  event,  or  ship 
schedule,  and  that  require  SUPSHIP,  ABS  and/or  NAVSEA  approval.  This  process  is  typically  implemented  via 
a  Memorandum  of  Agreement  (or  similar  document)  among  the  Shipbuilder,  NAVSEA  05,  SUPSHIP,  and  ABS. 
The  Shipbuilder  contacts  the  appropriate  SUPSHIP  Technical  Code  and  they  must  jointly  agree  to  enact  this 
process  for  each  emergent  issue  identified.  Once  agreed,  the  following  actions  are  taken: 

a.  Initial  Notification: 

Upon  identification  of  an  issue  determined  to  qualify  for  the  quick  circuit  process,  the  Shipbuilder  and  SUPSHIP 
Engineering  notify  all  parties  that  may  potentially  be  involved  in  the  resolution  of  the  issue.  The  purpose  of  this 
notification  is  to  ensure  all  parties  are  aware  of  the  issue  and  their  potential  involvement  in  the  development 
and/or  approval  of  the  resolution.  The  objectives  of  this  task  are: 

(1)  To  make  all  potential  stakeholders  aware  of  the  issue 

(2)  To  provide  a  summary/explanation  of  the  issue 

(3)  To  identify  the  ships/contracts  impacted  by  the  issue 

(4)  To  identify  the  potential  schedule  impact 

(5)  To  establish  a  preliminary  timeline  (target  Estimated  Completion  Date  (ECD))  for  resolving  the 
issue 

(6)  To  establish  a  date  and  time  for  follow-up  contact  (Telecom)  on  the  issue 

(7)  To  identify  points  of  contact 

b.  “Upfront”  Collaborative  Discussion: 

As  soon  as  practicable,  the  Shipbuilder,  SUPSHIP,  and  NAVSEA  (if  appropriate)  shall  meet/teleconference  to 
discuss  the  issue.  The  purpose  of  this  collaboration  is  to  have  an  “upfront”  discussion  on  the  issue  and  to  jointly 
develop  a  course  of  action  for  resolving  the  issue.  Typically,  the  Shipbuilder  engineering  department  will  provide 
the  details  of  the  issue  and  the  potential  options  for  resolving  the  issue. 

Note:  Additional  collaborative  discussions  may  be  necessary  to  resolve  complex  issues. 

The  objectives  of  this  task  are: 

(1)  To  jointly  develop  and  agree  on  a  course  of  action  for  resolving  the  issue 

(2)  To  identify  required  supporting  technical  products 

(3)  To  determine  and  identify  the  appropriate  approval  circuit  (TWHs) 

c.  Development  of  Plan  Details: 

The  Shipbuilder  engineering  department  will  typically  have  the  primary  responsibility  for  developing  the 
technical  analysis  associated  with  the  issue  and  its  resolution.  SUPSHIP  and  the  other  technical  shareholders 
(NAVSEA,  Planning  Yards,  etc...)  may  be  requested  to  provide  additional  information  and  technical  support. 

The  objectives  of  this  task  are: 

(1)  To  complete  technical  evaluation  of  the  issue 

(2)  To  validate  the  schedule  or  key  event  impact 

(3)  To  develop  technical  justification  for  accepting  any  out  of  spec  conditions  that  will  not  be 
corrected 

(4)  To  identify  and  develop  technical  details  for  resolving  the  issue 

(5)  To  identify  material  needed  to  accomplish  resolution 

(6)  To  identify  required  shop/trade/vendor  support 

(7)  To  develop  required  supporting  technical  products 
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d.  Collaborative  Review  of  Resolution  Plan 

The  Shipbuilder,  SUPSHIP,  and  NAVSEA  (if  appropriate)  will  meet/teleconference  to  discuss  and  review  the 
details  and  supporting  technical  products  associated  with  the  resolution  of  the  issue.  The  objectives  of  this  task 
are: 


(1)  To  review  and  discuss  the  technical  details  of  the  resolution  with  all  stakeholders 

(2)  To  identify  and  resolve  any  issues/concerns  related  to  the  resolution 

(3)  To  identify  any  additional  actions/supporting  technical  products  required  to  resolve  the  issue 

(4)  To  finalize  the  timeline  for  completing  and  submitting  the  supporting  technical  products  for 
approval 

(5)  To  verify  the  required  approval  circuit 

(6)  To  establish  a  timeline/ECD  for  completing  the  approval  process 

(7)  To  identify  any  portions  of  the  resolution  that  can  be  accomplished  prior  to  the  official 
completion  and  approval  of  supporting  documents 

e.  Develop/Finalize  Supporting  Technical  and  Approval  Products: 

The  Shipbuilder  engineering  department  develops  and  forwards  required  supporting  technical  products  to 
SUPSHIP  for  approval.  If  the  technical  products  require  NAVSEA  approval,  SUPSHIP  develops  the  forwarding 
documents  and  submits  the  package  to  the  applicable  Program  Office.  SUPSHIP  discusses/reviews  the  final 
resolution  with  the  appropriate  TWHs,  as  necessary,  to  ensure  that  the  resolution  is  acceptable  to  all  parties  and 
that  there  are  no  concerns  that  would  potentially  delay  the  approval  process.  The  objectives  of  this  task  are: 

(1)  To  complete  all  technical  products  needed  to  support  resolution 

(2)  To  submit  the  technical  product  package  to  SUPSHIP  for  approval 

(3)  To  forward  technical  products  to  the  established  outside  approval  circuit  when  required 

SUPSHIP  approves  all  technical  products  that  are  within  the  scope  of  their  technical  approval  authority. 

SUPSHIP  and  NAVSEA  approve  technical  products  for  issues  that  extend  beyond  the  boundaries  of  SUPSHIP 
technical  approval  authority.  SUPSHIP  provides  approval  notification  (verbal/written,  as  appropriate)  to  the 
Shipbuilder  engineering  department.  The  objective  of  this  task  is  to  quickly  obtain  the  appropriate  level  of 
customer  approval. 

The  RFP  includes  a  schedule  of  GFE,  GFI,  and  Government  Property.  Primary  responsibility  for  timely  delivery 
belongs  to  the  PARM,  but  the  SDM  and  associated  SIM  should  remain  aware  of  the  required  delivery  schedule 
and  monitor  possible  problem  areas.  As  events  on  the  schedule  or  tracking  system  approach,  the  SDM  must  keep 
informed  of  the  progress  and  likelihood  of  meeting  assigned  dates.  If  dates  will  not  be  met,  the  PARM  must 
determine  a  fallback  position  for  the  Program  Office.  Alternatives  and  costs  must  be  developed  for  presentation 
to  the  Program  Office. 

The  PARM  is  responsible  for  providing  and  validating  all  data  required  for  the  installation,  storage,  test, 
operation,  and  maintenance  of  equipment  being  furnished  to  the  Shipbuilder  by  the  government.  However,  the 
SDM  is  responsible  for  verifying  that  the  GFI  being  forwarded  to  the  Shipbuilder  is  consistent  with  the  Ship 
Specifications,  Contract  Drawings,  PPDs,  etc.  If  inconsistencies  are  identified,  the  SDM  will  work  with  the 
PARM  to  either  change  the  GFI  or  to  develop  a  contract  modification  to  ensure  consistency.  GFI  delivered  to  the 
Shipbuilder  becomes  part  of  the  contractual  baseline.  The  Program’s  IDE  provides  an  excellent  mechanism  for 
maintaining  GFE  and  GFI  up  to  date  and  available  to  the  entire  Design  Team. 
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Design  efforts  should  be  preceded  by  development  and  approval  of  a  Detail  Design  Engineering  Management 
Plan  and  study  guide(s).  The  end  of  the  Detail  Design  engineering  effort  occurs  at  delivery,  but  periodic  reviews 
conducted  by  the  SDM  are  needed  to  mark  progress  and  support  a  CDR  focusing  on  design  maturity  and  then  a 
PRR  focusing  on  manufacturing  readiness  at  the  start  of  construction.  Through  the  SDM’s  design  reviews  and 
Program  Manager’s  SPPCs  or  periodic  program  reviews,  the  Shipbuilder  must  demonstrate  that  the  design  is 
complete,  and  that  all  outstanding  design  issues  are  completely  resolved.  Status  of  GFE/GFI  issues  and  parallel 
development  efforts  are  also  tracked.  These  reviews  are  made  to  ensure  that  the  Shipbuilder  is  interpreting  the 
Ship  Specifications  and  drawings  as  intended  by  the  NAVSEA  TWHs  and  to  respond  to  Shipbuilder  questions 
about  the  design  or  intent  of  requirements,  within  contract  limitations.  If  omissions  are  found  in  Specification 
requirements  that  could  lead  to  future  problems,  these  omissions  can  be  corrected,  by  change  order  if  necessary. 
Recommended  changes  to  one  system  may  have  major  impacts  on  other  systems.  Care  must  be  exercised  during 
design  reviews  not  to  impose  unilateral  changes  on  the  Shipbuilder.  As  long  as  the  drawings  meet  Specification 
requirements,  the  only  way  the  Shipbuilder  can  be  forced  to  change  is  by  a  contract  change  order.  However  the 
Shipbuilder  may  elect  to  change  if  it  appears  to  be  to  his  benefit.  A  proper  attitude  by  all  concerned  is  critical 
during  design  reviews.  The  Engineering  Management  Plan  should  identify  key  participants  for  each  design 
review.  In  general,  these  design  reviews  should  not  be  scheduled  to  coincide  with  the  Program  Office  quarterly 
program  review  because  key  individuals  may  be  needed  at  both  reviews  at  the  same  time.  The  SDM  and 
associated  SIM  should  attend  all  quarterly  program  reviews  to  insure  the  technical  effects  of  decisions  are 
understood.  An  agenda  and  exit  criteria  should  be  established  for  each  design  review.  Typically,  the  Shipbuilder 
will  prepare  the  agenda  and  identify  the  exit  criteria  for  SDM  review  and  concurrence,  with  the  Program  Office 
responsible  for  making  the  final  decision. 

Detail  Design  should  conclude  with  a  CDR  (SETR  for  the  Product  Baseline)  in  conjunction  with  a  TRB  and  SSB. 
Again,  the  CDR  requires  extensive  preparatory  work,  similar  to  the  PDR,  but  this  time  focused  primarily  on  the 
maturity  of  the  Detail  Design.  If  the  vessel  is  to  be  ABS  classed,  ABS  should  have  been  asked  to  conduct  a 
design  review  of  all  artifacts  that  relate  to  the  appropriate  Rule  set.  For  applicable  T-ships,  a  Detail  Design 
Assessment  letter  shall  be  sent  signifying  that  no  “fatal  flaws”  exist  which  will  preclude  the  vessel  ultimately 
receiving  ABS  classification.  Again,  careful  planning  for  this  review  should  start  early  in  the  phase. 

Following  the  CDR,  a  PRR  is  normally  held  to  assess  manufacturing  readiness.  Facilities,  staffing,  training, 
procurement,  GFE,  GFI,  first  article  testing,  and  delivery  of  a  new  technology  to  the  Shipbuilder  should  all 
dovetail  with  the  notional  lead  ship  construction  schedule.  Projected  production  costs  should  be  within  bounds  to 
meet  the  total  lead  ship  cost.  Per  contract,  only  after  successful  completion  of  the  PRR  can  ship  construction 
begin.  In  some  cases,  a  phased  PRR  may  be  employed  to  enable  early  commencement  of  fabrication  of 
assemblies  and  sub  assemblies  in  order  to  comply  with  schedule  constraints. 

After  satisfactory  completion  of  the  PRR,  the  first  Gate  6  can  proceed  -  assessing  overall  program  health 
including  readiness  for  production.  Follow-on  Gate  6  reviews  will  be  conducted  to  endorse  or  approve  the  CPD, 
review  program  health  prior  to  and  post  Milestone  C  and  the  FRP  DR,  and  serve  as  forums  for  Configuration 
Steering  Boards  (CSBs)  which  are  required  to  review  proposed  major  changes  in  ship  configuration  and 
associated  cost. 

A  major  objective  for  DD&C  is  achievement  of  ship  certification  by  the  PEO,  based  upon  system  level 
certifications  conducted  by  TWHs  or  their  designated  agents  in  accordance  with  a  ship  master  certification  plan. 
This  includes  matters  such  as  the  following.  See  Appendix  S  for  a  summary  of  current  certification  requirements. 
Three  mechanisms  for  executing  the  certification  process  are: 

•  Review  and  approval  of  many  documents,  including  DREs,  deliverables,  drawings,  calculations, 
reports,  Engineering  Change  Proposals  (ECPs),  and  other  technical  documents 

•  Attendance  at  design  reviews,  SPPCs,  and  other  reviews  conducted  throughout  the  phase  to  track 
progress  against  schedule  and  to  identify  any  potential  problem  areas 

•  Witnessing  of  tests  and  review  of  test  reports 
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Achieving  these  objectives  requires  extensive  preparatory  work.  A  Master  Certification  Plan  should  be  available 
at  the  stai't  of  this  phase  to  guide  the  organization  and  management  of  the  certification  process.  Agreements,  such 
as  MOAs,  will  likely  be  required  to  obtain  needed  support  from  other  organizations.  The  Certification  Plan 
should  have  been  reviewed  and  approved  as  soon  as  possible  during  Preliminary  Design  so  that  the  associated 
certification  criteria  could  be  applied  as  first-order  influences  in  the  design  development  process. 

The  “Certification  Results  Summary  Memo”  will  document  the  status  of  all  the  certification  efforts  in  the  Design 
Certification  Matrix.  The  memo  will  be  co-authored  by  the  SDM,  associated  SIM  and  the  Waterfront  CHENG, 
and  signed  out  by  CSE  SHIPS  to  the  Program  Manager.  Outstanding  certification  issues  will  be  identified,  and 
related  risks  assessed.  This  memo  will  be  an  important  technical  basis  for  the  “Readiness  for  Trials  Memo”. 

The  “Readiness  for  Trials  Memo”  should  be  jointly  authored  by  the  SDM  and  the  Waterfront  CHENG,  and  signed 
out  as  a  serialized  memo  by  CSE  SHIPS  to  the  Program  Manager.  The  memo  will  address  key  outstanding 
technical  risks  (including  recommended  mitigation  actions).  The  memo  will  also  provide  an  overall  go/no  go 
recommendation  from  a  technical  standpoint,  and  will  address  any  operational  restrictions. 

Ideally,  the  follow-ship  technical  data  package  will  consist  of  a  reissue  of  the  lead  technical  data  package. 
However,  the  follow-ship  package  will  need  to  consider  all  modifications  and  change  orders  from  the  lead  ship. 
Also  considered  will  be  OPNAV  directed  changes  in  characteristics,  INSURV  items  if  the  lead  ship  has 
completed  trials,  and  changes  not  incorporated  in  the  lead  ship  because  of  expense  to  change  drawings  or 
hardware.  The  extent  of  work  to  be  accomplished  will  have  to  be  negotiated  with  the  Program  Office  in 
consideration  of  the  budget  and  schedule  constraints. 

The  SDM  shall  prepare  a  Turnover  Book  for  the  successor  In-Service  SDM  and  coordinate  technical  turnover 
from  SUPSHIP  CHENG  to  RMC/Naval  Shipyard  CHENG.  The  Turnover  Book  shall  be  issued  as  an  attachment 
to  a  serialized  memo.  At  a  minimum,  the  Turnover  Book  shall  contain: 

•  Design  History 

•  List  of  Design  Features  to  facilitate  modernization 

•  Summary  of  Service  Life  Allowances  and  stability  status 

•  Ships  Force  Contact  Information 

•  Placemat 

•  Safe  Operating  Envelopes 

•  List  of  significant  technical  risks  and  status  with  respect  to  their  mitigation 

•  List  of  all  outstanding  deficiencies  (trial  cards,  ABS  Outstanding  Recommendations,  DFS,  warranty 
work,  etc.)  and  current  status 

•  List  of  equipment  warranties 

•  A  description  of  how  to  gain  access  to  the  Ship  Selected  Records 

•  A  description  of  how  to  gain  access  to  the  LEAPS  Product  Model  (if  available)  or  Digital 
Product/Technical  Data  as  required  by  ASN(RD&A)  Memo  of  23  Oct  2004 

•  A  copy  of  Post  Shakedown  Availability  (PSA)  work  package  and  a  description  of  how  to  gain  access  to 
PSA  work  specs 

•  A  description  of  engineering  resources  available  (including  a  list  of  POCs)  in  the  event  that  tech  issues 
require  PSA  extended  warranty  period  design  support 

•  List  of  ECPs  and  other  modifications,  deviations,  and  waivers  not  accomplished  and  incorporated 
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APPENDIX  J 

CONVERSIONS  AND  MAJOR  MODERNIZATIONS 

During  the  typical  high-value  ship’s  service  life,  it  will  undergo  a  major  modernization  or  conversion  every  10  to 
15  years.  A  modernization  is  a  major  updating  of  equipment  and  systems  to  support  OPNAV  requirements.  A 
conversion  can  change  the  basic  mission  of  the  ship,  as  well  as  updating  equipment  and  systems,  and  the  ship 
designation  can  change  to  a  different  ship  type. 

An  abbreviated  design  process  for  both  conversions  and  major  modernizations  is  basically  a  simple  feasibility 
study  followed  by  Contract  Design.  The  primary  differences  between  major  modernizations/conversions  and  new 
ship  design  are  due  to  the  fact  that  the  basic  ship  and  ship  systems  already  exist.  An  SDM  is  usually  assigned  to 
ensure  proper  system  integration  for  these  projects  but  it  may  not  be  a  fulltime  job,  depending  on  the  scope  of  the 
effort.  Though  conceptually  appearing  less  complex,  the  constraints  of  existing  space,  weight,  ship’s  center  of 
gravity  above  the  keel  (KG),  electric  power,  accommodations,  structural  margins,  and  other  elements,  coupled 
with  the  realities  of  the  physical  condition  of  the  ship  obtained  during  ship  checks,  can  make  these  efforts 
extremely  challenging  for  the  SDM  and  Design  Team. 

Proper  implementation  of  Navy  Open  Architecture  and  use  of  MAS  technologies  should  reduce  the  scope, 
schedule,  and  cost  of  future  conversions  and  modernizations.  SDMs  and  SIMs  should  leverage  these 
opportunities  where  they  appear. 
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APPENDIX  K 
REACTIVATIONS 

At  the  end  of  a  ship’s  service  life  it  may  be  deactivated  and  assigned  to  the  Reserve  Fleet.  Sometimes,  after  the 
conclusion  of  a  ship’s  service  life,  another  phase  of  the  ship’s  life  cycle  may  be  initiated.  Ships  may  be 
reactivated  to  fulfill  again  the  original  mission  with  newer  equipment  or  to  fulfill  a  completely  different  mission. 
The  design  process  often  involves  a  simple  feasibility  study  followed  by  Contract  Design.  This  design  package 
generally  consists  of  work  packages  similar  to  those  created  for  overhauls. 

The  technical  responsibility  for  reactivation,  conversion,  or  major  modernization  may  reside  in  the  in-service 
SDM  or,  if  significantly  complex,  may  be  assigned  to  a  dedicated  SDM  in  SEA  05D/V.  Again,  constraints  of 
existing  ships  can  be  extremely  challenging.  The  battleship  reactivation  program  is  an  excellent  example  of  the 
possible  scope  of  such  an  effort,  using  approximately  77  man  years  of  effort  for  the  BB  62  (first  ship  to  be 
reactivated)  over  a  nine-month  period. 
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APPENDIX  L 

IN-SERVICE  ENGINEERING 

After  delivery  of  the  ship  to  the  Navy  and  the  completion  of  the  Post  Shakedown  Availability,  if  conducted,  SDM 
responsibility  will  typically  shift  from  the  New  Construction  SDM  to  the  In-Service  SDM.  This  transfer  will  be 
implemented  via  a  Turnover  Book  and  a  letter  of  transfer.  The  Turnover  Book  contains  details  of  all  technical 
issues  that  remain  unresolved.  The  Turnover  Book  should  be  jointly  developed  by  the  SDM  and  SUPSHIP 
CHENG  to  provide  to  the  In-Service  SDM  and  RMC/Naval  Shipyard  CHENG. 

The  preponderance  of  the  life  span  of  ships,  systems,  and  equipment  is  spent  in-service.  A  service  life  in  excess  of 
30  years  is  now  almost  routine  practice.  The  Fleet  Modernization  Program  (FMP),  now  implemented  through 
ship  maintenance,  provides  the  management  structure  by  which  characteristics  of  ships  in  the  Fleet  are  improved. 
Such  improvements  are  effected  as  either  program  or  Fleet  alterations.  The  SDM  will  coordinate  the  Naval 
Systems  Engineering  Directorate’s  (SEA  05)  participation  in  the  alteration  program  including  technical  review 
and  approval  and  involvement  of  ABS  if  the  ship  is  ABS  classed. 

The  responsibility  for  the  maintenance  and  modernization  of  in-service  ships  is  split  among  many  organizations. 

In  general,  the  Fleet  is  responsible  for  routine  preventative,  condition  based,  and  corrective  maintenance.  The  In- 
Service  SDM  is  primarily  concerned  with  addressing  technical  issues  associated  with  design  deficiencies, 
modernization,  alterations,  safe  operation  of  ships  and  ship  systems  with  degraded  equipment/systems,  and  safe 
operation  of  ships  and  ship  systems  when  using  equipment/systems  in  a  non-traditional  manner. 

The  exact  timing  of  the  shift  of  responsibility  for  a  given  ship  from  the  New  Construction  SDM  to  the  In-Service 
SDM  will  vary  from  ship  to  ship.  In  general,  it  will  occur  no  earlier  than  Ship  Delivery,  and  no  later  than  the 
Obligation  Work  Fimiting  Date  (OWED).  In  many  cases,  between  delivery  and  the  assumption  of  full 
responsibility  by  the  In-Service  SDM,  responsibility  will  be  shared  with  the  New  Construction  SDM.  The  New 
Construction  SDM  will  generally  retain  responsibility  for  correcting  trial  card  deficiencies,  Warrantee  Work,  and 
the  PSA  work,  while  the  In-Service  SDM  will  take  on  all  remaining  SDM  responsibilities.  SEA  05D/V  should 
issue  a  Turnover  Plan  detailing  the  timing  of  the  shift  of  responsibility  before  ship  delivery.  In  particular,  the 
transition  plan  shall  detail  technical  authority  assignments  during  the  period  between  delivery  and  OWED.  This 
Turnover  Plan  shall  also  include  any  special  instructions  for  the  Turnover  Book  described  in  Appendix  K. 

The  RMC  CHENG  is  responsible  and  accountable  for  all  engineering,  technical  work,  and  technical  decision¬ 
making  accomplished  by  his  or  her  assigned  activities  as  defined  by  NAVSEAINST  5400.95E  ( hyperlink ).  Ship 
and  work  period  specific  MOAs  are  issued  to  delineate  agreements  between  the  RMC  CHENG  and  other 
activities  involved  in  the  construction,  conversion,  and  refit  or  repair  work.  Note  that  Aircraft  Carriers  employ 
the  SUPSHIP  CHENGs  with  the  Shipyards  for  these  roles. 

SDM  Roles  and  Duties 

In  today’s  environment  of  constrained  in-house  resources,  SDMs  provide  essential  technical  leadership  in  guiding 
the  Navy’s  Design  Team  under  the  overall  direction  of  a  Ship  Program  Manager.  To  strengthen  that  relationship, 
SDMs  have  the  trust  of  the  management,  as  reflected  by  granting  SDMs  warranted  technical  authority  for  Total 
Ship  Systems  Engineering  and  Total  Ship  Integration  on  their  assigned  ships.  The  SDM  must  be  a  trusted 
technical  leader  for  the  in-service  Program  Manager,  TYCOMs,  and  the  ships’  Commanding  Officers. 

Independent  and  objective,  the  SDM  must  facilitate  the  timely  resolution  of  technical  issues  through  rapid 
assessment,  involvement  of  key  stakeholders  (including  Fleet,  Program  Offices,  and  technical  authorities)  and 
expert  communication  of  issues  and  acceptable  resolution  options  to  decision  makers.  The  SDM  is  counted  on  to 
know  the  technical  risks  for  his/her  ships  and  be  able  to  articulate  the  risks  (consequence  and  probability)  along 
with  proposed  mitigation  efforts.  The  SDM  must  have  a  thorough  working  knowledge  of  specifications  and  plans 
used  to  maintain  ships,  as  well  as  class  specific  applicable  technical  specifications,  standards,  and  drawings. 
Relationships  with  other  PEOs  concerning  the  ship  class  are  essential  as  well. 
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The  role  of  the  SDM  is  focused  on  the  “Design”  of  in-service  ships.  In  particular,  the  SDM  is  concerned  with 
how  well  the  design  of  the  ship,  as  well  as  the  physical  implementation  of  that  design,  is  meeting  the  ship’s 
operational  requirements.  The  SDM  must  therefore  have  a  good  understanding  of  the  operational  requirements  of 
the  assigned  ships  as  documented  in  CDDs.  The  SDM  must  also  know  the  physical  condition  of  the  ships  as 
reported  in  inspections/surveys/weight  reports,  and  Casualty  Reports  (CASREPs).  The  SDM  is  expected  to 
participate  in  periodic  INSURV  Underway  Material  Inspections  (UMIs)  to  maintain  current  awareness  of  the 
condition  of  his/her  assigned  ships.  The  SDM  must  understand  the  remaining  Service  Life  Allowances  for  all 
ships  under  his/her  cognizance  as  well  as  the  stability  status  and  the  basis  for  the  stability  status  for  each  ship.  A 
thorough  knowledge  of  risk  analysis  with  respect  to  Departure  From  Specifications  (DFS)  adjudication  and 
Integrated  Class  Maintenance  Plan  (ICMP)  deviations  is  required.  The  SDM  must  be  thoroughly  knowledgeable 
in  the  many  aspects  of  In  Service  Engineering  (ISE).  The  SDM  must  be  familiar  with  the  roles  the  In  Service 
Engineering  Agents  (ISEA)  are  fulfilling  for  their  ships  and  where  gaps  exist.  The  SDM  must  also  be  familiar 
with  the  role  and  actions  being  taken  by  the  respective  maintenance  activity  for  his/her  ship  type.  For  surface 
ships  this  is  the  Surface  Ship  Life  Cycle  Maintenance  Activity  (SSLCM)  and  for  carriers  this  is  the  Carrier 
Planning  Activity  (CPA).  The  SDM  is  expected  to  develop  relationships  with  RMCs,  especially  the  RMC 
CHENG,  and  Naval  Shipyards  in  order  to  be  a  resource  as  well  as  influence  ship  repair,  maintenance,  and 
modernization  practices. 

The  SDM  is  also  responsible  for  leading  the  review  of  major  alterations  to  the  ship’s  configuration  to  ensure  that 
the  changes  are  safe,  will  work,  incorporate  appropriate  Human  Systems  Integration  processes  and  do  not 
unknowingly  degrade  performance  in  other  mission  areas.  Where  needed,  the  SDM  will  ensure  the  Program 
Office  performs  or  directs  the  performance  of  shipboard  testing,  shipboard  monitoring,  modeling,  simulation,  and 
analyses  to  accomplish  the  duties  listed  here.  The  SDM  should  coordinate  the  review  of  condition-based 
maintenance  records  and  other  maintenance  and  consumable  records  to  identify  opportunities  for  reducing  life 
cycle  cost  and  improve  operational  availability.  The  SDM  will  be  responsible  for  providing  inputs  to  update 
applicable  sections  of  the  General  Specifications  for  Overhaul  (GSO).  The  SDM  is  responsible  for  advising 
Program  Offices  to  allocate  resources  to  develop  or  maintain  appropriate  Safe  Operating  Envelopes  for  each  ship 
(if  needed).  The  SDM  is  responsible  for  ensuring  appropriate  technical  data  is  kept  up  to  date  within  the  SEA  05 
and  NAVSEA  Incident  Room  virtual  technical  library  to  support  incident  response.  Should  a  ship  experience 
significant  damage,  the  SDM  will  lead  the  Headquarters  analysis  and  evaluation  efforts  to  support  Navy 
leadership.  The  SDM  shall  maintain  appropriate  documentation  and  lessons-learned  for  sharing  knowledge  with 
other  In-Service  SDMs  as  well  as  New  Construction  SDMs.  The  In-Service  SDM  is  expected  to  know  the  TWH 
structure,  where  the  knowledge,  expertise,  and  authority  resides  for  all  functional  areas  associated  with  his/her 
ships,  and  coordinate  all  technical  issues  with  appropriate  TWHs  and  Program  Office.  Wherever  possible,  the 
SDM  will  resolve  technical  conflicts  within  the  competency  and  enterprise.  When  necessary,  the  SDM  will 
employ  the  chain-of-command  to  resolve  issues.  The  goal  should  be  for  the  NAVSEA  Technical  Authority  to 
speak  with  one  voice  to  the  customer. 

Relationships  with  Engineering  Field  Representatives  and  Naval  Shipyard  Representative  Offices 

Engineering  Field  Representatives  and  Naval  Shipyard  Representative  Offices  are  NAVSEA’ s  eyes  and  ears  on 
the  waterfront.  They  are  committed  to  ensuring  waterfront  technical  compliance  as  well  as  liaising  with  the 
waterfront  presence  of  Fleet  and  TYCOM  N43  organizations.  Developing  a  strong  working  relationship  with 
these  personnel  will  enable  the  SDM  to  get  honest  and  accurate  feedback  directly  from  the  deckplates,  similar  to 
the  Program  Manager  Representative’s  (PMR’s)  relationship  to  the  Program  Office. 
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CLASSRON  Relationship  (Note  that  CLASSRONs  are  being  disestablished  and  this  process  will  be  changing.) 

Where  applicable,  SEA  05  SDMs  for  Surface  Forces  (SURFOR)  ships  or  one  of  their  support  staff  are  expected  to 
be  additional  duty  to  the  CFASSRON  for  their  respective  class  of  ship.  They  are  expected  to  represent  the  Virtual 
SYSCOM  as  a  whole,  not  just  SEA  05.  They  are  expected  to  function  as  a  part  of  the  CFASSRON  N4 
organization,  directly  responsible  to  each  CFASSRON  Commander  to  accomplish: 

•  Technical  community  liaison  for  class  maintenance,  repair,  and  modernization  issues 

•  Fiaison  with  Regional  NAVSEA  Engineering  Field  Representatives  (EFR)  to  accomplish  onsite 
coordination  issues  that  the  SDM  or  CFASSRON  N43  may  not  be  able  to  conduct 

•  Provide  technical  direction  and  management,  as  necessary,  to  integrate  HM&E,  Combat  Systems, 
Aircraft  systems  and  their  interfaces,  and  C4ISR  modernization  installations  for  in-service  surface 
ships 

•  Risk  analysis  and  Departure  from  Specification  (DFS)  screening  with  RMCs,  TYCOMs,  and  Program 
Offices 

•  R&D  support  and  analysis 

•  T&E  support  and  analysis 

•  Systems  engineering  and  integration  support 

•  Reviews  planned  SCDs/CONOPS  (including  maintenance  sections)  for  technical  adequacy,  and 
provide  comments  to  the  Program  Office  as  part  of  the  SHIPMAIN  process 

•  TMA/TM1  Issues  program  support  for  each  CFASSRON 

•  Review  ICMP  deferral  requests.  Provide  appropriate  technical  support  and  information 

•  Coordinate  CFASSRON  interaction  with  the  various  warfare  centers,  present  tasking  requests  to  PEO 
Ships  for  approval  of  funding 

•  Participate  in  CFASSRON  metrics  monitoring  and  offer  NAVSEA  input  on  improvements,  root  causes 
for  below  benchmark  observations  and  duplications  with  metrics  tracked  by  other  NAVSEA  Codes  or 
PEOs 

•  Provide  training  to  the  CFASSRON  on  general  technical  authority,  differences  with  Programmatic 
Authority,  the  Virtual  SYSCOM  and  products  and  services  already  produced  by  the  Program  Offices 
and  SYSCOMs  such  as  equipment  monitoring  programs,  ISE  products,  modernization  planning 
initiatives,  etc. 

Fiaison  Action  Record 

There  is  a  requirement  for  a  formal  technical  liaison  system  among  ISE  activities,  Planning  Yards  (PYs), 
SUPSHIPs,  Overhaul  Yards,  Space  and  SPAWAR,  PARMs,  AITs,  Ship  Program  Managers  (SPMs),  and  other 
organizations  involved  in  the  modernization  process.  Details  for  the  Fiaison  Action  Record  (FAR)  process  are 
identified  in  the  JFMM. 

The  technical  liaison  system  described  herein  shall  be  used  for  the  following  reasons: 

•  Technical  Information 

•  Interpretation  of  Drawings,  Specifications,  etc. 

•  Material  Identification 

•  Change  Requests 

•  Planning  Yard  approval  of  Drawings 
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The  primary  document  to  be  used  in  this  Liaison  System  is  the  Liaison  Action  Record  (LAR);  however,  it  is  not 
the  intent  to  require  the  use  of  LARs  where  other  mechanisms  exist  such  as  the  direct  liaison  between  the 
overhauling  activity  and  the  PY  On-Site  Representative  (OSR). 

Any  changes  to  modernization  drawings  which  affect,  material  specifications,  pipe  stress  levels  or  distribution, 
system  design  or  operational  characteristics/features,  component  or  fitting  selection,  ratings  and  MIL-SPECS, 
structural  integrity,  power  requirements,  compartment/topside  arrangements  or  require  insertion  in  drawing  for 
follow  on  ships  are  not  permitted  except  where  concurred  on  by  the  PY.  This  concurrence  can  be  obtained  either 
via  LAR  or  the  OSR  process.  Where  approved  changes  require  the  revision  of  drawings,  the  appropriate  activity 
will  modify  these  on  a  priority  basis.  This  does  not  apply  to  Nuclear  Propulsion  Plant  matters  under  the 
cognizance  of  SEA  08. 

Departure  from  Specification 

Specifications  are  engineered  requirements  such  as  type  of  materials,  dimensional  clearances,  vibration  levels, 
flow  rates,  and  physical  arrangement  to  which  ship  components  are  purchased,  installed,  tested,  and  maintained. 
All  ships  are  designed  and  constructed  to  specific  technical  and  physical  requirements.  It  is  imperative  that  every 
effort  be  made  to  maintain  all  ship  systems  and  components  to  their  designed  specifications.  There  are  occasions 
when  the  applicable  specifications  cannot  be  met.  In  these  cases,  the  non-conformance  to  specifications  is 
controlled  with  a  DFS  as  identified  in  the  JFMM.  The  waterfront  technical  authority  policy  is  described  in 
NAVSEAINST  5400.95E. 

During  a  maintenance  action,  a  DFS  is  required  for  lack  of  compliance  with  cognizant  documents,  drawings,  etc. 
For  “as  found”  conditions  during  maintenance,  the  TYCOM,  ship  and  Fleet  Maintenance  Activity  (FMA)  (if 
involved)  must  evaluate  the  non-compliance  using  the  guidance  of  the  JFMM.  For  “as  found”  conditions  or 
equipment  failures  during  operations  that  result  in  non-compliance  with  cognizant  documents,  drawings,  etc.,  the 
ship  and/or  TYCOM  (if  in  port)  must  evaluate  the  condition  or  failure  using  the  guidance  of  the  JFMM  to 
determine  if  the  non-conforming  condition  meets  the  criteria  as  a  Major  DFS.  If  it  is  not  non-compliant,  a  DFS  is 
not  required  and  the  non-conforming  condition  will  be  entered  in  the  ship’s  Current  Ship’s  Maintenance  Project 
(CSMP). 

It  is  incumbent  upon  ships,  FMAs,  and  TYCOMs  to  discuss  a  potential  DFS  as  early  as  possible  (prior  to  the  work 
close  out  or  component  assembly  if  possible)  to  determine  direction  of  actions,  and  alternatives  to  the  DFS. 

Every  effort  must  be  made  to  correct  each  deficiency  prior  to  equipment/system  operation  or  underway  of  the 
ship.  If  a  DFS  has  to  be  submitted,  the  request  for  it  must  be  processed  as  soon  as  possible  to  enable  an 
engineering  evaluation  of  the  DFS  request  and  approval/disapproval  to  be  granted  without  disrupting  ship’s 
operations. 

A  DFS  is  classified  as  either  Major  or  Minor  depending  on  its  significance.  Care  must  be  exercised  in  evaluating 
and  determining  the  type  of  DFS.  A  major  DFS  is  one  that  affects  performance,  durability,  reliability, 
maintainability,  interchangeability,  effective  use  or  operation,  weight  or  appearance,  health  or  safety,  system 
design  parameters,  compartment  arrangements,  or  assigned  function.  A  DFS  which  is  not  a  Major  DFS  is 
considered  to  be  a  Minor  DFS. 

A  DFS  is  approved  as  either  permanent  or  temporary  depending  on  the  nature  of  the  non-compliance  and 
technical  determination  of  whether  the  condition  needs  to  be  repaired.  A  temporary  DFS  requires  subsequent 
action  to  correct  the  non-compliance  and  is  approved  with  specific  direction  regarding  duration  and  actions 
necessary  to  clear.  A  Major  DFS  accepting  a  temporary  repair  or  condition  is  approved  by  the  TYCOM  following 
concurrence  by  an  Authorized  Technical  Authority.  A  Minor  DFS  accepting  a  temporary  repair  will  be  approved 
by  the  TYCOM.  All  permanent  Minor  (and  Major)  DFSs  will  be  approved  by  NAVSEA  except  those  identified 
in  the  JFMM,  which  may  be  dispositioned  by  the  TYCOM. 

Request  for  DFS  for  nuclear  systems  will  be  neither  requested  nor  approved.  If  a  ship  or  FMA  has  a  question, 
problem,  or  is  unable  to  comply  with  nuclear  specifications,  request  for  technical  resolution  will  be  made  using  an 
LAR.  Formal  resolution  of  the  LAR  is  required  prior  to  reactor  plant  or  propulsion  plant  startup. 
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If  a  nuclear  powered  ship  or  nuclear  capable  FMA  is  unable  to  comply  with  specifications  for  reactor  plant 
systems  or  components,  then  a  review  of  SEA  08  requirements  shall  be  requested.  In  general,  technical  resolution 
to  questions  or  problems  for  reactor  plant  systems  or  components  requires  use  of  a  liaison  inquiry  according  to  the 
requirements  of  SL720-AA-MAN-030,  Surface  Ships  and  Carriers  Entitled  Process  for  Modernization 
Management  and  Operations  Manual  and  Integrated  Project  Teams  for  Aircraft  Carrier  Maintenance  (IPT4ACM). 

Steam  Plant  Action  Requests/Steam  Plant  Liaison  Inquiry 

If  a  ship  or  FMA  has  a  question,  problem,  or  is  unable  to  comply  with  non-nuclear  specifications,  technical 
assistance  is  available  from  the  Propulsion  Plant  Engineering  Activity  (PPEA).  The  PPEA  was  formed  to  provide 
an  additional  technical  resource  for  assisting  operational  aircraft  carriers  with  technical  or  operational  issues  not 
associated  with  modernization  installation  and  configuration  control.  PPEA  Liaison  services  are  requested  using 
the  Steam  Plant  Action  Request  (SPAR).  The  SPAR  allows  the  Fleet  and  overhaul  activities  to  submit  requests  to 
the  PPEA  for  technical  assistance  on  non-Ship  Alteration  related  issues;  the  SPAR  is  not  intended  to  replace  the 
LAR  process  described  above  or  non-nuclear  LARs  submitted  to  the  Hull  Planning  Yard.  The  PPEA  can  request 
information,  disseminate  technical  information  associated  with  the  Steam  Plant  to  the  Fleet/overhaul  activities,  or 
direct  work  that  does  not  require  a  drawing  change  or  affect  system  configuration  control  using  the  Steam  Plant 
Liaison  Inquiry.  Procedures  for  preparing  SPAR/Steam  Plant  Liaison  Inquiries  (SPLIs)  are  discussed  in 
NAVSEA  0989-LP-043-0000,  Commissioned  Surface  Ship  General  Reactor  Plant  Overhaul  and  Repair 
Specification. 

Trouble  Reports 

The  Trouble  Report  is  the  vehicle  to  identify  significant  problems  encountered  in  the  construction,  repair,  and 
maintenance  of  naval  ships.  NAVSEAINST  4700. 17,  Preparation  and  Review  of  Trouble  Reports,  provides 
consolidated  requirements  for  the  preparation  and  review  of  Trouble  Reports. 

Ship  Change  Documents 

The  original  Ship  Maintenance  (SHIPMAIN)  Program  was  developed  to  streamline  maintenance  planning, 
execution,  and  oversight  within  the  Surface  Fleet.  After  inception,  SHIPMAIN  was  broadened  to  include 
modernization  planning  for  all  surface  ship  and  aircraft  carrier  programs.  This  was  later  extended  to  include 
modernization,  execution,  and  feedback.  Among  the  many  goals  and  precepts  of  the  modernization  leg  of 
SHIPMAIN  are:  Upfront  review  and  approval  of  shipboard  changes  early  in  their  life  to  ensure  only  the  most 
important  changes  are  designed/developed;  a  reduction  of  the  multiple  types  of  changes  (Machinery  Alterations 
(MACHALTS),  ECPs,  Ordnance  Alterations  (ORDALTs),  etc.)  to  a  single  designation  and  form  established  as  a 
Ship  Change  Document  (SCD);  a  formalized  process  for  evaluating  SCDs  as  they  evolve  to  include  Technical 
Assessment  Team  (TAT)  review,  CBA  and  military  utility  or  Alteration  Figure  of  Merit  (AFOM)  parameters;  a 
ship  change  and  Navy  Modernization  Plan  approval  process  ensuring  only  approved  changes  are  funded  for 
development  and  shipboard  installation.  The  SHIPMAIN  modernization  component  ultimately  evolved  into  the 
Navy  Modernization. 

Program  and  the  business  rules  and  operating  guidance  are  invoked  in  the  Surface  Ship  and  Carrier  Entitled 
Process  for  Modernization  (SSCEM)  Management  and  Operations  Manual  (SL720-AA-MAN-030).  This  manual 
provides  overall  guidance  for  TAT  reviews. 
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APPENDIX  M 

AIRCRAFT  CARRIER  MODERNIZATION 

The  IDEA  Operations  Manual  was  developed  to  define  the  Carrier  modernization  process  under  the  IDEA 
concept.  It  complements  the  Navy  Modernization  Process  (NMP)  that  supplants  the  SHIPMAIN  Cross 
Functional  Team  Four  (CFT-4)  Entitled  Process,  including  SL720-AA-MAN-030,  Surface  Ships  and  Carriers 
Entitled  Process  for  Modernization  Management  and  Operations  Manual,  Integrated  Project  Teams  for  Aircraft 
Carrier  Maintenance  (IPT4ACM)  and  JFMM  ( hyperlink ),  and  other  related  modernization  directives. 

The  entitled  process  significantly  modifies  the  FMP  and  reduces  over  40  alteration  types  to  two  categories,  Fleet 
(TYCOM)  alterations  and  program  (SYSCOM  or  PEO)  alterations,  streamlines  and  consolidates  a  number  of 
existing  modernization  practices,  processes,  meetings,  and  supporting  documents  and  provides  a  single, 
hierarchical  decision  making  process  for  modernizing  surface  ships  and  aircraft  carriers.  The  goal  of  the  entitled 
process  is  to  populate  the  President’s  budget  with  approved,  fully  funded  alterations,  selected  based  on  technical, 
war  fighting,  readiness,  and  cost  benefits  using  one  structured  process  involving  TYCOM  and  OPNAV  senior 
decision  makers. 

The  process  is  based  on  approved  business  rules.  It  consists  of  a  five -phase  process  (Preliminary  Analysis, 
Concept  Design,  Design  Development,  Implementation,  and  Installation/Checkout/Feedback)  supported  by 
Decision  Points  at  the  end  of  Phases  I-III  and  Readiness  Assessment  during  Phase  IV. 

A  single  database  is  maintained  by  SEA  04.  The  SCD,  which  replaces  the  Justification  Cost  Form,  Ship 
Alteration  Record,  in-service  ECP,  and  all  other  alteration  documents  used  in  the  FMP,  will  be  entered  and 
tracked  in  the  database  from  inception  through  installation  in  the  last  applicable  ship.  Only  SCDs  entered  in  the 
database  are  considered  for  inclusion  in  modernization  plans  for  specific  hulls. 

Involvement  of  Fleet,  OPNAV,  TYCOMs,  SYSCOMS,  and  PEOs  in  the  decision-making  process  is  incorporated 
through  the  use  of  three  boards  of  stakeholders  at  the  0-6,  1  and  2-star  Admiral  and  3-star  Admiral  level.  Voting 
members  of  the  boards  represent  appropriate  Fleet  and  OPNAV  organizations.  SYSCOM  and  PEO  representation 
is  included  to  validate  the  readiness  of  the  alteration  to  proceed  to  the  next  steps. 

The  SDM  for  In-Service  Carriers  is  responsible  for  the  Carrier  SCD  Technical  Assessment  Team  Review  program 
as  a  whole  and  specifically  is  the  Technical  Authority  responsible  for  the  completeness  of  all  necessary  technical 
reviews.  As  such,  the  In-Service  SDM  shall  designate  Core  TAT  Eeads  for  each  functional  area  to  review  and 
adjudicate  the  appropriate  level  of  review. 

The  TAT  reviews  and  concurs  with  each  phase  of  an  SCD.  Core  and  Virtual  TATs  consisting  of  SYSCOM  and 
PEO  technical  personnel  review  the  SCD  to  ensure  the  SCD  is  technically  feasible  and  to  identify  any  ship 
integration  issues  that  may  impact  its  overall  benefit  to  the  Fleet,  such  as  Weight  and  Moment,  HVAC 
requirements,  interoperability,  certifications  or  conjunctiveness  with  other  changes.  ILS  considerations  are  also 
assessed. 

The  TAT  review  shall  assess  the  technical  feasibility  of  an  SCD  as  it  is  developed,  using  technical  experts, 
including  TWH,  as  applicable.  The  TAT  review  shall  be  limited  to  comments  technical  in  nature.  Administrative 
or  grammatical  changes  will  not  be  made  unless  required  to  clarify  technical  intent  or  if  made  in  conjunction  with 
technical  comments  on  the  same  section  of  the  SCD.  Questions  regarding  the  technical  merit  of  the  changes  shall 
be  submitted  to  the  Deputy  Ship  Design  Manager  for  In-Service  Carriers  (DSDM)  or  directly  to  the  appropriate 
SDM. 
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Air  Craft  Carrier  Refueling  Complex  Overhaul 

When  an  aircraft  carrier  transitions  from  new  construction  to  in  service,  technical  authority  shifts  from  SEA  05  V3 
(CVN  78  Class)  or  V2  (CVN  68  Class)  to  SEA  05V1.  SEA  05V 1  leads  the  interface  of  systems  engineering 
efforts  with  the  TWH  community  for  in-service  carriers,  and  are  warranted  to  make  integration  decisions.  As 
such,  the  In-Service  Carrier  SDM  leads  the  technical  efforts  of  the  In-Service  Aircraft  Carrier  Program  Office 
(PMS  312E).  Midway  through  its  service  life,  an  aircraft  carrier  undergoes  a  Refueling  Complex  Overhaul.  The 
planning  and  execution  oversight  for  this  extended  availability  is  SCN  funded  via  PMS312D,  and  the  engineering 
effort  is  led  by  SEA  05 V2.  PMS  31 2D  is  the  branch  organization  within  PEO  Carriers  responsible  for  managing 
overall  direction  of  the  RCOH  program  to  re -deliver  the  ship  within  cost/schedule/capabilities.  This  organization 
develops  and  executes  budgeting,  plans,  policies,  procedures,  and  acquisitions  pertaining  to  the  RCOH  program. 
Subsequent  to  the  RCOH,  ownership  is  transitioned  back  to  PMS312E  and  SEA  05V 1. 

Aircraft  Carrier  Baseline  Authorized  Work  Package 

The  Baseline  Authorized  Work  Package  (BAWP)  contains  the  Aircraft  Carrier  Class  Maintenance  Plan 
maintenance  requirements  sequenced  to  support  the  aircraft  carrier’s  50-year  life  and  operating  cycles,  while 
maintaining  materiel  readiness  and  combat  ready  aircraft  carriers.  Due  to  the  technical  nature  of  the  decisions 
being  made,  all  potential  maintenance  reprogramming  requests  must  be  reviewed  at  the  appropriate  technical  level 
to  minimize  compromising  long-term  readiness  and  prevent  non-executable  maintenance  bow  waves. 

The  Carrier  Planning  Activity  (CPA)  develops  BAWP  work  items  derived  from:  higher-level  mandatory 
requirements  (e.g..  Naval  Ships  Technical  Manual  [NSTM],  GSO,  etc.),  SHIPMAIN  CFT4  modernization  plan, 
the  Reactor  Plant  Planning  Yard  (RPPY)  baseline  (e.g.,  reactor  plant  modernization,  Reactor  Plant  Manual 
maintenance,  etc.),  Intermediate  (I)/Depot  (D)  level  PMS,  Program  Office  IMP  life  cycle  strategies  (e.g.,  Carrier 
Availability  Planning  System  [CAPS],  Life  Cycle  maintenance  strategies,  etc.),  and  other  sources  (e.g.,  Team  One 
initiatives,  hot  wash  lessons-leamed,  ships  force  items,  etc.).  The  BAWP  work  items  will  be  grouped  according 
to  one  of  the  following  source  codes  that  identify  change  request/notification  requirements  for  non¬ 
accomplishment: 

•  Mandatory  -  Requires  a  change  request  for  non-accomplishment 

•  Modernization  -  Requires  a  change  request  for  non-accomplishment  under  the 

SHIPMAIN  CFT-4  Entitled  Process 

•  Discretionary  -  Requires  notification  to  the  CPA  (not  a  change  request)  for  non-accomplishment 

CPA  will  also  coordinate/negotiate  a  combined  mitigation  strategy,  ensure  evaluation/input  from  all  applicable 
technical  authorities  and  Engineering  Agents  (EAs)  (CPA,  SEA  08,  SEA  05,  NAVAIR,  SPAWAR,  Naval  Surface 
Warfare  Centers  [NSWCs],  RPPY,  PPEA,  etc.),  and  other  stakeholders.  If  not  already  submitted,  they  will  advise 
CNAF  if  a  formal  DFS  is  to  be  submitted. 

Technical  Authorities  and  EAs  will  evaluate  BAWP  work  item  DFS  and  mitigation  strategies  to  determine  the 
technical  impacts  and  risks  associated  with  the  work  reprogramming  or  change-in-scope.  Additionally,  they  will 
provide  recommendations,  with  appropriate  justifications,  for  approval  or  disapproval  and  alternative  mitigation 
strategies  or  actions  as  required  to  reduce  risk.  If  required,  they  will  adjudicate  changes  to  the  mitigation  actions 
with  CNAF  and  stakeholders. 

Finally,  they  will  provide  approval  or  disapproval  recommendations  to  the  PMS  312  BAWP  Change 
Requests/Notifications  Disposition  letter. 
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Ship  Change  Documents 

For  aircraft  carriers,  SEA  05V  maintains  the  process  for  the  technical  review  of  SCDs.  Technical  assessments  are 
conducted  by  Core  TAT  Leads.  Under  the  cognizance  of  SEA  05V,  Core  TAT  Leads  are  responsible  for  ensuring 
that  the  appropriate  technical  stakeholders  including  CVN  68  Class  Engineering  Configuration  Manager  (ECM), 
Engineering  Agents,  Life  Cycle  Managers  (LCM),  SEA  08  and  TWHs  review  SCDs.  There  are  currently  six 
Core  TAT  Leads:  Aviation,  Auxiliary,  Hull,  Electrical/Networks,  Propulsion,  and  Warfare  Systems/Command, 
C41.  When  the  Refueling  Complex  Overhaul  (RCOH)  program  or  new  construction  program  has  a  more  urgent 
need  for  an  SCD,  the  Core  TAT  Lead  will  assign  the  responsibility  for  managing  the  virtual  TAT  review  to  his 
counterpart,  who  will  act  as  the  Virtual  TAT  Lead.  This  will  allow  for  more  efficient  and  timely  use  of  resources 
but  also  preserves  the  single  entry  and  exit  points  for  TAT  reviews.  Figure  M-l  depicts  the  TAT  review  process 
while  Table  M-l  presents  the  TAT  review  timeline.  Additional  details  of  the  SEA  05V  process  is  documented  in 
a  Memorandum  of  Understanding  among  Commander,  Naval  Sea  Systems  Command  (COMNAVSEA)  SEA 
05V,  COMNAVSEA  SEA  08P,  COMNAVAIR  AIR  4.1,  and  PEO-CV  PMS  312. 

To  provide  a  consistent  process  for  both  NOFORN  and  unclassified  SCDs  and  to  address  current  problems 
associated  with  the  Navy  Data  Environment  (NDE)  software,  tasking  for  review  of  SCDs  may  be  accomplished 
using  SEA  05’s  MOS,  assignment  within  NDE-Entitled  Process  (EP),  or  via  email  for  outside  activities.  Upon 
completion  of  a  review,  comments  and  supporting  data  will  be  posted  to  the  NDE.  SEA  05V  will  post  supporting 
data,  technical  input,  comments,  and  recommendations  for  a  particular  SCD  in  a  common  file  structure  within  the 
PEO  Carriers  IDE. 

The  Core  TAT  Lead  recommends  to  the  TAT  Change  Manager  (CM)  that  SCDs  be  approved,  approved  with 
changes,  or  returned  for  rework.  SCDs  that  are  approved  with  changes  contain  minor  comments  that  can  be 
added  to  the  next  SCD  phase  but  do  not  affect  the  technical  contents. 

Minor  changes  for  Phase  111  SCDs  can  be  captured  by  supplying  the  comments  as  an  attachment  in  the  SCD. 

SCDs  that  require  significant  change  will  be  sent  back  to  the  TAT  CM  with  a  recommendation  for  rework.  The 
TAT  Lead  will  determine  whether  SCD  changes  are  minor  or  major  based  on  how  they  affect  technical  content. 

When  a  legacy  alteration  has  to  be  converted  to  an  SCD  to  complete  the  installation  for  the  class,  the  Phase  Ill 
SCD  will  be  evaluated  by  the  TAT  lead  to  determine  the  following: 

•  Concurrence  to  the  legacy  documentation  such  as  a  SHIP  ALT  Record  (SAR)  or  Alteration  Equivalent 
to  Repair  (AER)  is  available  and  still  germane 

•  Interfaces  and  system  impacts  have  not  changed 

•  New  requirements  have  not  resulted  in  a  need  to  modify  the  legacy  alteration 

•  There  are  no  outstanding  LARs  written  against  legacy  alteration  and  all  existing  LARs  have  been 
incorporated  into  the  Phase  III  SCD 

If  all  four  are  evaluated  as  true,  the  TAT  lead  will  recommend  approval  of  the  SCD  to  the  TAT  CM.  The 
approved  SAR  will  be  provided  as  an  attachment  to  the  SCD.  If  it  is  a  SEA  08  interest  alteration,  a  copy  of  the 
SCD  with  legacy  SAR  will  be  provided  to  the  applicable  SEA  08  codes  for  information.  It  is  incumbent  upon  the 
Submitter  to  provide  historical  documentation  on  the  legacy  alteration  in  question. 

A  Phase  III  SCD  can  also  be  initiated  when  a  legacy  Justification  Cost  Form  (JCF)  has  been  approved.  In  this 
case  the  SCD  will  go  through  the  full  TAT  review  process. 

The  TAT  Leads  may  provide  supporting  data  for  CBA  when  the  SCD  is  in  the  initiation  or  submittal  stage,  but 
this  is  outside  of  their  chartered  responsibility.  They  will  assess  ILS  elements  for  technical  accuracy.  The 
Submitter  is  responsible  for  populating  the  fielding  plan,  CBA,  and  AFOM. 

Phase  I  and  Phase  II  (not  including  Phase  II  non-permanent  changes  or  prototypes)  SCDs  will  only  be  reviewed 
by  the  TAT  Lead  except  where  the  TAT  Lead  deems  that  a  virtual  TAT  review  is  necessary.  The  SCDs  may  be 
distributed  for  information. 
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Figure  M-l.  TAT  Review  Process  Diagram 


M-4 


S9800-AC-MAN-01 0 


Table  M-l.  TAT  Review  Timeline 


Note:  Phase  III  SCDs  documenting  previously  approved  legacy  alterations  also  fall  under  the 
1-2  week  processing  timeline. 
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APPENDIX  N 

TYPICAL  DESIGN  PHASE  CHARACTERISTICS 


The  following  provides  a  summary  of  typical  design  phase  characteristics 


Exploratory 
Design  and 
Force 

Architecture 

Pre-AoA 

AoA 

Pre-Preliminary 

Preliminary 

Contract 

Detail 

FMP 

Reactivation 

Conversion 

Purpose 

Rough  order  of 
magnitude  and 
even  feasibility 
level  ship  and 
system  studies 
of  force  options 
and 

technologies. 

Rough  order  of 
magnitude  or 
feasibility  level 
ship  and  system 
studies  to 
support  a  CBA, 
SWARF,  or 
other  analysis 
for  ICD  then 

MDD  to  define 
AoA 

performance/ 
cost  trade 
space. 

Feasibility  level 
ship  and  system 
studies  to  define 
AoA 

alternatives. 

Start  ramp  up 
from  Feasibility 
to  Preliminary 
Design  level 
effort  for  the 
selected  AoA 
concept  to 
support 
requirements 
and  budget 
definition  for 

CDD  finalization, 
Milestone  A,  and 
possibly  Ship 
Specification 
development 
and  contracting 
for  Preliminary 
Design. 

Focus  on 
establishing 
ship  size, 
external 
configuration, 
and  the  overall 
allocation  of 
space  to  various 
functions  -  the 
Functional 
Baseline. 

Translate  the 

results  of 

Preliminary 

Design  into  a 

biddable 

technical 

package. 

Production  of  all 
design  and 
engineering 
deliverables 
required  to 
construct,  test, 
and  certify  the 
ship. 

SHIPALTs  to 
provide  for  ship 
improvements. 

Up  to  Contract 
Design  level 
effort  to  support 
reactivation. 

Up  to  Contract 
Design  level 
effort  to  support 
conversion. 

Alternative 

Approaches 

SEA  05  in-house 
with  lab  and/or 
contractor 
support. 

SEA  05  in-house 
with  Navy  lab 
and/or 
contractor 
support. 

SEA  05  in- 
house  with  Navy 
lab  and/or 
contractor 
support  to 
provide  inputs  to 
AoA  Director. 
SEA  05  may 
provide  AoA 
Director. 

SEA  05  in- 
house  with  Navy 
lab  and/or 
contractor 
support. 

SEA  05  in- 
house  with  Navy 
lab  and/or 
contractor 
support  or 
contracting  for 
conduct  of  a 
Shipbuilder 
Preliminary 
Design. 

SEA  05  in- 
house  with  Navy 
lab  and/or 
contractor 
support  or 
contracting  for 
conduct  of  a 
Shipbuilder 
Contract  Design. 

Shipbuilder 

design. 

In  accordance 
with  Fleet 
Modernization 
Program. 

SEA  05  in- 
house  with  Navy 
lab  and/or 
contractor 
support  or 
contracting  for 
conduct  of  a 
Shipbuilder 
Design. 

SEA  05  in- 
house  with 

Navy  lab  and/or 
contractor 
support  or 
contracting  for 
conduct  of  a 
Shipbuilder 
Design. 
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Exploratory 
Design  and 
Force 

Architecture 

Pre-AoA 

AoA 

Pre-Preliminary 

Preliminary 

Contract 

Detail 

FMP 

Reactivation 

Conversion 

Lead,  Workload 
and  Participants 

SCM  with  a  few 
part  time 
engineers;  SIM 
participation  as 
applicable. 

SCM  with  a  few 
part  time 
engineers;  SIM 
participation  as 
applicable. 

SCM  orSDM 
with  a  few  part 
time  engineers; 
SIM  participation 
as  applicable. 

SDM  starting 
with  the  AoA 
Feasibility 

Design  support 
team  and 
starting  to 
expand  to 
Preliminary 
Design  levels 
and  participants 

SDM  with  an 
effort  of  over  1 

00  man  years 
using  mostly 
part  time  people 
for  a  combatant 
design. 

Collocated  core 
team  including  a 
DIM,  PNA,  PME, 
general 
arrangements, 
structures, 
weights,  SIM, 

C4I  integrator, 
and  one  or  two 
naval 

architectural 

generalists. 

SDM  with  an 
effort  of  about 
200  man  years 
using  mostly 
part  time  people 
for  a  combatant 
design. 

Collocated  core 
team  including  a 
DIM,  PNA,  PME, 
Specifications 
Manager, 
general 
arrangements, 
structures, 
weights  and 
stability, 
propulsion, 
electrical,  SIM, 
C4I  integrator, 
HVAC,  fluids, 
mechanical, 
deck,  HSI,  two 
or  three  naval 
architectural 
generalists,  and 
support. 

SDM  with 
organization 
similar  to  that  for 
Contract  Design 
but  with 
emphasis  on 
review  of 
Shipbuilder 
deliverables. 
Addition  of 
SUPSHIP 
support.  Overall 
workload  may  or 
may  not 
significantly 
decrease. 

SDM  with  a 
small  support 
staff. 

SDM  with 
organization 
similar  to  that  for 
Contract 

Design 

SDM  with 
organization 
similar  to  that 
for  Contract 
Design. 

Duration  (See 
Note  1 ) 

3-6  months 

3-12  months 

3-12  months 

1-12  months 

6-12  months 

12-24+  months 

12-36+  months 

Ongoing 

12-36+  months 

1 2-36+  months 

Design  Reviews, 
SETRs  Reviews, 
Gates 

Event  Based 
Design  Reviews 

Event  Based 
Design  Reviews, 
ITR,  Gate  1 

Event  Based 
Design 

Reviews, 
Possible  SRR 
and  Gate  3  if 
CDD  is  entering 
Navy  staffing 
prior  to 

Milestone  A 

Event  Based 
Design  Reviews, 
SRR  and  Gate  3 
if  not  held  prior 
to  support  CDD 
submission  to 
Navy  staffing. 

Event  Based 
Design  Reviews, 
SFR  (SETR  for 
the  Functional 
Baseline),  Gate 

4,  and  possibly 
Gate  5  for  early 
verification  of 
RFP  content. 

Event  Based 
Design  Reviews, 
PDR  (SETR  for 
the  Allocated 
Baseline) 

Event  Based 
Design  Reviews, 
IBR,  FCA,  SVR, 
CDR  (SETR  for 
the  Product 
Baseline),  PRR, 
SPPCs,  Gate  6 

Gate  6,  ISR 

Event  Based 
Design  Reviews, 
PDR  (SETR  for 
the  Allocated 
Baseline) 

Event  Based 
Design 

Reviews,  PDR 
(SETR  for  the 
Allocated 
Baseline) 
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APPENDIX  O 

HISTORIC  TIMELINES  FOR  PRELIMINARY  AND  CONTRACT  DESIGN 


The  following  are  timelines  in  months  for  recent  Preliminary  and  Contract  Design  efforts.  Note  that  T-AKE 
efforts  were  delayed  because  of  funding  and  other  factors. 


Preliminary  Design 


DDG51 
LPD  17 

LHD  1 


Navy -9 


Navy -11 


Navy -7 


LHA(R)  Navy- 18 


CVN21  Navy -18 


TAKE  Navy  Point  Design -24 


Sealift  Navy  -  6++ 


DDX  Industry  -24 


LCS  Industry -12 

- _ 

MLP 


Industry  - 11 


ssc 


Navy- 11 


Contract  Design 


Navy  -  22 


Navy -25 


Navy- 16 

Collaborative  - 18 

Collaborative  - 18 

Industry -10 

Industry  - 15-19 

Industry  -24 

Industry -7 

Industry -6 

Navy  - 12 

-  v 

0-1 /(0-2  blank) 


APPENDIX  P 

TYPICAL  DESIGN  PHASE  DELIVERABLES 


Exploratory  Design 
and  Force 
Architecture 

Pre-AoA 

AoA 

Pre-Preliminary 

Preliminary 
(Functional  Baseline) 

Contract  (Allocated 
Baseline) 

Detail  (Product 
Baseline) 

General 

Management 

Study  Guide,  Annual 
Report,  Design 

Phase  Report 
including  Design 
FHistory,  Draft  Next 
Phase  EMP 

Design  Phase  EMP, 
Study  Guide(s), 
Schedule,  Budget, 
Annual  Execution 
Agreement,  Annual 
Report,  Design 

Phase  Report 
including  Design 
History,  Draft  Next 
Phase  EMP 

Design  Phase  EMP, 
Study  Guide(s), 
Schedule,  Budget, 
Annual  Execution 
Agreement,  Annual 
Report,  Design 

Phase  Report 
including  Design 
History,  Draft  Next 
Phase  EMP 

Design  Phase  EMP, 
Study  Guide(s), 
Schedule,  Budget, 
Annual  Execution 
Agreement,  Annual 
Report,  Design 

Phase  Report 
including  Design 
History,  Draft  Next 
Phase  EMP 

Design  Phase  EMP, 
Study  Guide(s), 
Schedule,  Budget, 
Annual  Execution 
Agreement,  Annual 
Report,  Design 

Phase  Report 
including  Design 
History,  Draft  Next 
Phase  EMP 

Design  Phase  EMP, 
Study  Guide(s), 
Schedule,  Budget, 
Annual  Execution 
Agreement,  Annual 
Report,  Design 

Phase  Report 
including  Design 
History,  Draft  Next 
Phase  EMP 

Design  Phase  EMP, 
Study  Guide(s), 
Schedule,  Budget, 
Annual  Execution 
Agreement,  Annual 
Report,  Design 

Phase  Report 
including  Design 

FI i story,  Draft  Next 
Phase  EMP, 
Shipbuilder  SEMP, 
Shipbuilder  Drawing 
Schedule,  Ship 
Drawing  Index, 
Shipbuilder  Progress 
Reports,  Monitoring 
of  Shipbuilder 
Progress 

Design  Tools 

Inputs  to  EMP  on 
planned  use  of 
design  tools 

Inputs  to  EMP  on 
planned  use  of 
design  tools 

Inputs  to  EMP  and 
SEP  on  planned  use 
of  design  tools 

Inputs  to  EMP  and 
SEP  on  planned  use 
of  design  tools 

Inputs  to  EMP  and 
SEP  on  planned  use 
of  design  tools 

Inputs  to  EMP  and 
SEP  on  planned  use 
of  design  tools 

Inputs  to  EMP  and 
SEP  on  planned  use 
of  design  tools 

Modeling  and 
Simulation 

Inputs  to  EMP  on 
planned  use  of 
Modeling  and 
Simulation; 
development  of 
Modeling  and 
Simulation  planning 
documentation 
including  VV&A  as 
needed 

Inputs  to  EMP,  on 
planned  use  of 
Modeling  and 
Simulation; 
development  of 
Modeling  and 
Simulation  planning 
documentation 
including  VV&A  as 
needed 

Inputs  to  EMP,  SEP 
and  Test  Planning 
on  planned  use  of 
Modeling  and 
Simulation; 
development  of 
Modeling  and 
Simulation  planning 
documentation 
including  VV&A  as 
needed 

Inputs  to  EMP,  SEP, 
and  Test  Planning 
on  planned  use  of 
Modeling  and 
Simulation; 
development  of 
Modeling  and 
Simulation  planning 
documentation 
including  VV&A  as 
needed 

Inputs  to  EMP,  SEP, 
and  Test  Planning 
on  planned  use  of 
Modeling  and 
Simulation; 
development  of 
Modeling  and 
Simulation  planning 
documentation 
including  VV&A  as 
needed 

Inputs  to  EMP,  SEP, 
and  Test  Planning 
on  planned  use  of 
Modeling  and 
Simulation; 
development  of 
Modeling  and 
Simulation  planning 
documentation 
including  VV&A  as 
needed 

Inputs  to  EMP,  SEP, 
and  Test  Planning 
on  planned  use  of 
Modeling  and 
Simulation; 
development  of 
Modeling  and 
Simulation  planning 
documentation 
including  VV&A  as 
needed 
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Exploratory  Design 
and  Force 
Architecture 

Pre-AoA 

AoA 

Pre-Preliminary 

Preliminary 
(Functional  Baseline) 

Contract  (Allocated 
Baseline) 

Detail  (Product 
Baseline) 

Risk  Management 

Risk  identification, 
assessment, 
mitigation  planning 
as  required  to 
support  design 

Risk  identification, 
assessment, 
mitigation  planning 
as  required  to 
support  design 

Risk  identification, 
assessment, 
mitigation  planning  as 
required  to  support 
design;  Start  to 
develop,  Risk 
Management  Plan 
and  Risk  Register. 

Execute  Risk 
Management  Plan. 
Maintain  Risk 

Register. 

Execute  Risk 
Management  Plan. 
Maintain  Risk 

Register. 

Execute  Risk 
Management  Plan. 
Maintain  Risk 

Register. 

Execute  Risk 
Management  Plan. 
Maintain  Risk 

Register.  Monitor 
Shipbuilder  Risk 
Management 

Program. 

Technology 
Assessment  and 
Development 

Technology 
assessment  and 
planning  as  required 
to  support  design 

Technology 
assessment  as 
required  to  support 
design,  Gate  1  and 
AoA  planning 

Technology 
assessment  as 
required  to  support 
design,  AoA  and  Gate 
2 

Technology 
assessment  and 
development  as 
required  to  support 
design  and  Gates 

Technology 
assessment  and 
development  as 
required  to  support 
design  and  Gates 

Technology 
assessment  and 
development  as 
required  to  support 
design,  Gates  and 
Milestone  B 

Technology 
assessment  and 
development  as 
required  to  support 
design  and  Gates 

Manufacturing 

Readiness 

Assessment 

Manufacturing 
readiness 
assessment  and 
planning  as  required 
to  support  design 

Manufacturing 
readiness 
assessment  as 
required  to  support 
design,  Gate  1  and 
AoA  planning 

Manufacturing 
readiness 
assessment  as 
required  to  support 
design,  AoA  and  Gate 
2 

Manufacturing 
readiness 
assessment  and 
development  as 
required  to  support 
Gates  and  design 

Manufacturing 
readiness 
assessment  and 
development  as 
required  to  support 
Gates  and  design 

Manufacturing 
readiness 
assessment  and 
development  as 
required  to  support 
design,  Gates  and 
Milestone  B 

Manufacturing 
readiness 
assessment  and 
development  as 
required  to  support 
design  and  Gates 

Mission  Scenarios, 
Threat  Sets, 

CONOPS  and  Design 
Reference  Mission 

Develop  mission 
scenarios,  Threat 

Sets,  CONOPS  and 
Design  Reference 
Mission 

Updates  as  required 

Updates  as  required 

Regulatory  Body 
Compliance 

Define  initial 
approach  and 
document  in  EMP 

Define  initial 
approach  and 
document  in  EMP 

Define  initial 
approach  and 
document  in  EMP 
and  SEP 

-  Ship  Specification 
inputs  as  required 

-  ABS  (for  T-ships  as 
applicable)  and  other 
reviews  of  the  Design 

-  Ship  Specification 
inputs  as  required 

-  ABS  (for  T-ships  as 
applicable)  and  other 
reviews  of  the  Design 

-  Ship  Specification 
inputs  as  required 

-  ABS  (for  T-ships  as 
applicable)  and  other 
reviews  of  the  Design 

ABS  (for  T-ships  as 
applicable)  and  other 
regulatory  reviews  of 
the  Design  and 
Inspections 

Concept  or  Feasibility 
Design 

ASSET  or  equivalent 

ASSET  or  equivalent 

ASSET  or  equivalent; 
sketches  and  other 
PowerPoint 
descriptions  to 
support  presentation 
to  AoA  IPTs. 
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Exploratory  Design 
and  Force 
Architecture 

Pre-AoA 

AoA 

Pre-Preliminary 

Preliminary 
(Functional  Baseline) 

Contract  (Allocated 
Baseline) 

Detail  (Product 
Baseline) 

Cost  Forms  and 

Cost  Estimate 

Cost  Forms  to 
support  SEA  05C 

ROM  level  cost 
estimates 

Cost  Forms  to 
support  SEA  05C 

ROM  level  cost 
estimates 

Cost  Forms  to 
support  SEA  05C 

ROM  level  cost 
estimates 

Cost  Forms  to 
support  SEA  05C 
budget  level  cost 
estimates 

Cost  Forms  to 
support  SEA  05C 
budget  level  cost 
estimates 

Cost  Forms  to 
support  SEA  05C 
budget  level  cost 
estimates 

-  Cost  Forms  to 
support  SEA  05C 
budget  level  cost 
estimates 

-  Shipbuilder  cost 
reporting 

SDS 

Develop  plan  for  Gate 
3  and  complete 
following  CDD 
approval  for  Gate  4 

Complete  following 
CDD  approval  for 

Gate  4 

Ship  Specification 

-  Specification 
Management  Plan 

-  May  start  and  even 
complete  and 
approve 

Specification 
depending  on 
Acquisition  Strategy 

May  start  and  even 
complete  and 
approve 

Specification 
depending  on 
Acquisition  Strategy 

Complete  and 
approve 

Specification 

-  Possible  change 
from  approved 

System  Specification 
to  an  approved 
Shipbuilding 
Specification 

-  Engineering 

Change  Proposals 

-  Waivers  and 
Deviations 

Data  Requirements 

DRL  inputs  as 
required  for 
contracting 

DRL  inputs  as 
required  for 
contracting 

DRL  inputs  as 
required  for 
contracting 

Review  of  DRL 
deliverables 

Ship  Product  Model 
(SPM) 

Define  initial 
approach  and 
document  in  EMP 

Define  initial 
approach  and 
document  in  EMP 

Define  initial 
approach  and 
document  in  EMP 
and  SEP 

-  Initial  SPM  and  SPM 
development  plan 

Update 

Update 

Shipbuilder  SPM 
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Exploratory  Design 
and  Force 
Architecture 

Pre-AoA 

AoA 

Pre-Preliminary 

Preliminary 
(Functional  Baseline) 

Contract  (Allocated 
Baseline) 

Detail  (Product 
Baseline) 

General 

Arrangements 

ASSET  or  equivalent 
assessment. 

ASSET  or  equivalent 
assessment. 

-  Initial  sketches 

-  Area/Volume 
summary 

-  General 

Arrangement 

Drawings  that  show 
major  subdivisions, 
compartments  and 
accesses  for  all 
decks 

-  Area/Volume 

Report 

-  General 

Arrangement 

-  Area/Volume 

Report 

-Tankage  Report 

-  FHabitability  Design 
Report 

-  Access  Study 

Report 

-  Weapons  Flandling 
Flow  Diagram 

-  Troop,  Cargo  and 
Vehicle  Flow 

Diagrams 

-  General 

Arrangement 

-  Area/Volume 

Report 

-  Tankage  Report 

-  FHabitability  Design 
Report 

-  Access  Study 

Report 

-  Weapons  Flandling 
Flow  Diagram 

-  Troop,  Cargo  and 
Vehicle  Flow 

Diagrams 

-  DRL  Deliverables 
such  as  Shipbuilder 
Product  Model 
outputs  and 
Arrangements 

Related  Technical 
Reports  such  as 
Equipment  Access 
Studies  for 
Maintenance  and 
Removal 
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Exploratory  Design 
and  Force 
Architecture 

Pre-AoA 

AoA 

Pre-Preliminary 

Preliminary 
(Functional  Baseline) 

Contract  (Allocated 
Baseline) 

Detail  (Product 
Baseline) 

Topside  Design 

-  Initial  sketches 

-  Topside 

Arrangement  that 
shows  major 
functional  areas 

-  Topside 
Arrangement 

-  Visibility  Study 

-  Panama  Canal 
Clearance  Report 

-  Bridge  Clearance 
Report 

-  Antenna 
Arrangement 

-  Topside 
Electromagnetic 
Compatibility 
Assessment 

-  EMC/RADHAZ 
Analysis  Report 
including  PIERO, 
HERF,  HERP,  NEMP, 
EMI 

-  TEMPEST 

-  Stack  Design 
Analysis  for  Airflow 
and  Dispersion 

-  Navigation  Lights 
Drawing 

-  Flight  Deck 
Arrangement  with 
Airflow  Assessment 

-  Weapons  Pointing, 
Firing,  Blast  and 
Radiation  Zones 

-  Topside 

Arrangement 

-  Visibility  Study 

-  Panama  Canal 
Clearance  Report 

-  Bridge  Clearance 
Report 

-  Antenna 
Arrangement 

-  Brass  Model 

-  Topside 
Electromagnetic 
Compatibility 
Assessment 

-  EMC/RADHAZ 
Analysis  Report 
including  HERO, 
HERF,  HERP,  NEMP, 
EMI 

-TEMPEST 

-  Stack  Design 
Analysis  for  Airflow 
and  Dispersion 

-  Navigation  Lights 
Drawing 

-  Flight  Deck 
Arrangement  with 
Airflow  Assessment 

-  Weapons  Pointing, 
Firing,  Blast  and 
Radiation  Zones 

-  DRL  Deliverables 
such  as  Shipbuilder 
Product  Model 
outputs  and  Topside 
Design  Related 
Technical  Reports 

Major  Equipment  List 

Major  Equipment  List 

Major  Equipment  List 

Major  Equipment  List 

Major  Equipment  List 

Major  Equipment  List 

-  Equipment  History 
Data  Package 

-Certification  of 

compliance/ 

equivalency 
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Exploratory  Design 
and  Force 
Architecture 

Pre-AoA 

AoA 

Pre-Preliminary 

Preliminary 
(Functional  Baseline) 

Contract  (Allocated 
Baseline) 

Detail  (Product 
Baseline) 

GFE/GFI 

Define  notional  list  of 
GFE  for  cost 
estimating 

Define  notional  list  of 
GFE  for  cost 
estimating 

Define  notional  list  of 
GFE  for  cost 
estimating 

Define  notional  list  of 
GFE  and  GFI  for  cost 
estimating  and  for 
contracting  if 
required 

Define  notional  list  of 
GFE  and  GFI  for  cost 
estimating  and  for 
contracting  if 
required 

Define  notional  list  of 
GFE  and  GFI  for  cost 
estimating  and  for 
contracting  if 
required 

Track  GFE  and  GFI 
delivery  status  and 
impact  on  design 

Survivability  (SWBS 
072) 

Cost/  performance 
trade-off  studies 

Cost/  performance 
trade-off  studies 

Cost/  performance 
trade-off  studies 

Cost/  performance 
trade-off  studies 

-  Survivability 
Assessment 

-  Damage  Control 
Systems  Design 
Report 

-  Preliminary  Vital 
Space  List 

-  Collective  Protection 
System  General 
Arrangements 

-  Degaussing  System 
Design  Report 

-  Survivability 
Assessment 

-  Damage  Control 
Systems  Design 
Report 

-  Vital  Space  List 

-  Collective  Protection 
System  General 
Arrangements 

-  Air  Lock  and  Decon 
Station  Drawings 

-  Degaussing  System 
Specifications 

-  Survivability 
Assessment 

-  DRL  Deliverables 
such  as  Shipbuilder 
Product  Model 
outputs 

-  Shock 

Management  Plan 

-  Equipment  Shock 
Test  Procedures 

-  Mathematical 

Model  Reports 

-  Shock  Dynamic 
Analysis  Report 

-  Equipment  Shock 
Test  Reports 

-  Shock  Qualification 
Data  Sheets 

-  List  of  Foundation 
Shock  Design 
Drawings 

-  Damage  Control 
Book 

-  Degaussing  System 
Drawings 
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Exploratory  Design 
and  Force 
Architecture 

Pre-AoA 

AoA 

Pre-Preliminary 

Preliminary 
(Functional  Baseline) 

Contract  (Allocated 
Baseline) 

Detail  (Product 
Baseline) 

Noise  and  Vibration 
(SWBS  073) 

-  Noise  and  Vibration 
Analysis  Report 

-  Noise  and  Vibration 
Analysis  Report 

-  Noise  Control 
Program  Plan 

-  Noise 

Control/Design 

History  Booklet 

-  Equipment  Vibration 
Test  Validation 

Report 

-  Noise  Control 
Program 

Management  Report 

-  SONAR  Self  Noise 

-  Radiated  Noise 

-  SONAR  Self  Noise 

-  Radiated  Noise 

-  SONAR  Self  Noise 

-  Radiated  Noise 

Reliability, 

Availability,  and 
Maintainability 
(SWBS  076) 

RAM-C  Report  (if  an 
AoA  discriminator) 

RAM-  C  Report 

RAM-  C  Report 
Update 

RAM-  C  Report 

Update 

Track  and  review 
Shipbuilder  RAM-C 
deliverables  including 
equipment  and 
systems  RAM  data 
and  failure  mode  and 
effects  analysis 
reports 

Environmental, 

Safety,  and 
Occupational  Health 
(ESOH)  (SWBS  077 
for  safety) 

ESOH  risk 
identification, 
assessment, 
mitigation  planning  as 
required  to  support 
design 

ESOH  risk 
identification, 
assessment, 
mitigation  planning  as 
required  to  support 
design 

ESOH  risk 
identification, 
assessment, 
mitigation  planning 
as  required  to  support 
design 

ESOH  Working  Group 
and  review  of  design 
deliverables 

ESOH  Working 

Group  and  review  of 
design  deliverables 

-  WSESRB  and/or 
SWIT  review  letters 
and 

recommendations 

-  ESOH  Working 
Group  and  review  of 
design  deliverables 

-  ESOH  Working 
Group  and  review  of 
design  deliverables 

-  Shipbuilder  ESOH 
Program  and  Working 
Group 
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Exploratory  Design 
and  Force 
Architecture 

Pre-AoA 

AoA 

Pre-Preliminary 

Preliminary 
(Functional  Baseline) 

Contract  (Allocated 
Baseline) 

Detail  (Product 
Baseline) 

Seaworthiness 
(SWBS  079) 

-  Dimensions  and  hull 
form  coefficients 

-  Dimensions  and  hull 
form  coefficients 

-  Body  plan  and 
appendages 

-  Preliminary  Lines 
Plan  and 
appendages 

-  FHull  Lines 

-  FHydrostatic  Analysis 
Report 

-  Curves  of  Form 

Data 

-  FHull  Lines 

-  Plydrostatic  Analysis 
Report 

-  Curves  of  Form 

Data 

DRL  Deliverables 
such  as  Shipbuilder 
Product  Model 
outputs  and 
Hydrostatic 
Descriptions  such  as 
Final  Hull  Lines  and 
Curves  of  Form 

-  Propulsor  Design 

-  Control  Surface  and 
Appendage  Design 
Report 

-  Propulsor  Design 

-  Control  Surface  and 
Appendage  Design 
Report 

-  Roll  Stabilization 
Study  Report 

DRL  Deliverables 
such  as  Shipbuilder 
Product  Model 
outputs  and 

Propulsion  System 
Technical  and  Test 
Reports 

-  Seakeeping 
assessment  (if  a 
concern) 

-  Seakeeping 
assessment  (if  a 
concern) 

-  Seakeeping 
assessment  (if  a 
concern) 

-  Seakeeping 
assessment  (if  a 
concern) 

Seakeeping  and 

Maneuvering 

Assessment 

Seakeeping  and 

Maneuvering 

Assessment 

DRL  Deliverables 
such  as  Shipbuilder 
Product  Model 
outputs  and  Steering 
System  Technical 
and  Test  Reports 

-  Initial  Powering 
Prediction 

-  Initial  Powering 
Prediction 

-  Initial  Powering 
Prediction 

-  Initial  Powering 
Prediction 

-  Speed  and  Power 
Analysis 

-  Endurance  Analysis 

-  Speed  and  Power 
Analysis 

-  Endurance  Analysis 

-  Speed  and  Power 
Analysis 

-  Endurance  Analysis 

-  Preliminary  Model 
Test  Plan 

-  Preliminary  Model 
Test  Report 

-  Model  Test  Plan 

-  Model  Test  Report 

-  Model  Test  Plan 

-  Model  Test  Report 
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Exploratory  Design 
and  Force 
Architecture 

Pre-AoA 

AoA 

Pre-Preliminary 

Preliminary 
(Functional  Baseline) 

Contract  (Allocated 
Baseline) 

Detail  (Product 
Baseline) 

Human  Systems 
Integration  (SWBS 
080) 

HSI  planning  and 
analysis  as  required 
to  support  design 

HSI  planning  and 
analysis  as  required 
to  support  design 

HSI  planning  and 
analysis  as  required 
to  support  design 

HSI  Working  Group 
and  review  of  design 
deliverables 

HSI  Working  Group 
and  review  of  design 
deliverables 

HSI  Working  Group 
and  review  of  design 
deliverables 

-  HSI  Working  Group 
and  review  of  design 
deliverables 

-  Shipbuilder 

Program  and  Working 
Group 

Manpower  and 
Personnel  (SWBS 
088) 

Initial  low  fidelity 
estimates 

Initial  low  fidelity 
estimates 

Initial  low  fidelity 
estimates 

-  Preliminary  Ship 
Manning  Document 
for  Gate  4 

-  Preliminary  Ship 
Manning  Document 
for  Gate  4 

-  Preliminary  Ship 
Manning  Document 
for  Gate  4 

-  Specification  inputs 
as  required 

-  Specification  inputs 
as  required 

-  Specification  inputs 
as  required 

Training  (SWBS  089) 

-  Navy  Training 
Systems  Plan  for 

Gate  4 

-  Navy  Training 
Systems  Plan  for 

Gate  4 

-  Navy  Training 
Systems  Plan  for 

Gate  4 

-  Crew  Familiarization 
Curriculum 

-  Specification  inputs 
as  required 

-  Specification  inputs 
as  required 

-  Specification  inputs 
as  required 

Testing  (SWBS  090- 
095) 

-  May  start  and  even 
approve  Certification 
Matrix  depending  on 
Acquisition  Strategy 

-  May  start  and  even 
approve  Certification 
Matrix  depending  on 
Acquisition  Strategy 

-  Certification  Matrix 

-  Specification  inputs 
as  required 

-  Comprehensive 

Test  Plan 

-  Test  Status 

-  Specification  inputs 
as  required 

-  Specification  inputs 
as  required 

-  Test  Reports 

-  Builders  Trial 
Readiness,  Memo, 
Procedures, 

Schedule,  Agenda, 
Report 

-  Ship  Acceptance 
Test  Readiness, 
Memo,  Procedures, 
Schedule,  Agenda, 
Report 
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Exploratory  Design 
and  Force 
Architecture 

Pre-AoA 

AoA 

Pre-Preliminary 

Preliminary 
(Functional  Baseline) 

Contract  (Allocated 
Baseline) 

Detail  (Product 
Baseline) 

Mass  Properties 
(SWBS  096) 

-  Three-digit  weight 
report 

-  Three-digit  weight 
report 

-  Three-digit  weight 
report 

-  Three-digit  weight 
report 

-  Preliminary  Design 
Weight  Estimate 

-  Weight  Control  Plan 

-  Weight  Trend 

Report 

-  Contact  Design 
Weight  Estimate 

-  20  Station 
Longitudinal  Weight 
Distribution  Report 

-  Weight  Control  Plan 

-  Contract  Weight 
Control  Clause  (as 
applicable) 

-  Weight  Moment  of 
Inertia  Estimate 

-  Weight  Control  Plan 

-  Accepted  Weight 
Estimate 

-  Mass  Properties 
Design  Data  Sheet 

-  Input  Data  Cards 

-  Government 
Furnished  Material 
Report 

-  Contract 

Modification  Reports 

-  Quarterly  Weight 
Reports 

-  Launching 
Information 

-  Final  Weight 

Report 

-  Accepted  Ship 
Report 

-  Intact  Stability 
Analysis 

-  Intact  Stability 
Analysis 

-  Intact  and  Damage 
Stability  Analysis 

-  Intact  and  Damage 
Stability  Analysis 

-  Intact  and  Damage 
Stability  Report 

-  Limiting  KG  and 
Subdivision 
Displacement  Limit 
and  Limiting  Drafts 

-  Flooding  Water 
Levels  (V  Lines) 

-  Intact  and  Damage 
Stability  Report 

-  Limiting  KG  and 
Subdivision 
Displacement  Limit 
and  Limiting  Drafts 

Flooding  Water 

Levels  (V  Lines) 

-  Preliminary  and 

Final  Inclining 
Experiment  Reports 
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Exploratory  Design 
and  Force 
Architecture 

Pre-AoA 

AoA 

Pre-Preliminary 

Preliminary 
(Functional  Baseline) 

Contract  (Allocated 
Baseline) 

Detail  (Product 
Baseline) 

Hull  Structure  (SWBS 
100) 

-  Parametric  ratio 

-  Parametric  ratio 

-  Midship  section 

-  Midship  and  typical 
sections  drawings 

-  Midship  Section 

-  Longitudinal 

Sections 

-  Scantlings 

-  Structural  Trade-Off 
Study  Report 

-  Midship  and/or 
Longitudinal  Section 

-  Shell  Expansion 
and  Typical  Sections 

-  Scantlings 

-  Decks 

-  Platforms 

-  Superstructure 

-  Structural  Details 

-  Hull 

Structure/Longitudinal 
Strength  Report 

-  Structural  Profile 
and  Sections  - 
Primary  and  General 

-  Strength  and  Inertia 
Curves  for  Critical 

Hull  Loading 
Conditions 

-  Structural  Design 
Criteria  Report 

-  Superstructure  and 
Mast  Vibration 
Analysis 

DRL  Deliverables 
such  as  Shipbuilder 
Product  Model 
outputs  and  Technical 
and  Test  Reports 

Producibility 

Address  producibility 
in  Design  Report 

Preliminary 
Producibility  Report 

Producibility  Report 

DRL  Deliverables 
such  as  Shipbuilder 
Product  Model 

Outputs 
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Exploratory  Design 
and  Force 
Architecture 

Pre-AoA 

AoA 

Pre-Preliminary 

Preliminary 
(Functional  Baseline) 

Contract  (Allocated 
Baseline) 

Detail  (Product 
Baseline) 

Propulsion  Plant 
(SWBS  200) 

-  Endurance  Fuel 
Calculation 

-  Plant  type  and 
number  of  propulsors 

-  Endurance  Fuel 
Calculation 

-  Plant  type  and 
number  of 
propulsors 

-  Endurance  Fuel 
Calculation 

-  Plant  type  and 
number  of 
propulsors 

-  Propulsion  System 
Report 

-  Propulsor  Design 
Results 

-  Propulsor  Shafting 
Sizing  Calculations 

-  Preliminary 
Machinery 
Arrangement 

Shafting  and 

Intake/Uptake 

Drawings 

-  Propulsion  System 
Report 

-  Propulson  Design 
Results 

-  Propulsor  Shafting 
Sizing  Calculations 

-  Propulsor 
Hydrodynamic 

Design  Report 

-  Propulsor  Shaft 
Alignment  Analysis 
Report 

-  Propeller  Cavitation 
Inception  and 

Radiated  Noise 

Report 

-  Machinery 
Arrangement 

Shafting  and 

Intake/Uptake 

Drawings 

-  DRL  Deliverables 
such  as  Shipbuilder 
Product  Model 
outputs 

-  Propulsion  Shafting 
Material  Test 

Report 

-  Propulsion  Shafting 
System  Conference 
Report 

-  Propeller  Viewing 
Conference  Report 

-  Propeller  Test 
Reports 

-  CP  Propeller 
Calculations 

-  Test  Reports 

Machinery 
Arrangements 
(SWBS  201) 

-  Rough  sizing/ 
arrangement  via 
ASSET  or  equivalent 

-  Rough  sizing/ 
arrangement  via 
ASSET  or  equivalent 

-  Block  Machinery 
Arrangements 

-  Block  Machinery 
Arrangements 

Machinery 

Arrangements 

Drawing 

Machinery 

Arrangements 

Drawing 

DRL  Deliverables 
such  as  Shipbuilder 
Product  Model 
outputs  and  any 
requirements  for  3D 
Modeling  of  the 
Machinery  Spaces 

Machinery  Plant 
Central  Control 
(SWBS  202) 

Machinery 

Centralized  Control 
System  Design 

Report 

Machinery  Control 
System  Design 

Report 

-  DRL  Deliverables 
such  as  Shipbuilder 
Product  Model 
outputs  and  Physical 
or  Virtual  Mock  Ups 
of  the  Control  Spaces 

-  Test  Reports 
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Exploratory  Design 
and  Force 
Architecture 

Pre-AoA 

AoA 

Pre-Preliminary 

Preliminary 
(Functional  Baseline) 

Contract  (Allocated 
Baseline) 

Detail  (Product 
Baseline) 

Electric  Plant  (SWBS 
300) 

-  Electric  Power  Load 
Analysis 

-  Electric  Power  Load 
Analysis 

-  Electric  Power  Load 
Analysis 

-  One  Line  Diagram 

-  Electric  Power  Load 
Analysis 

-  One  Line  Diagram 
for  Ship  Service, 
Electric  Propulsion, 
Emergency,  and 

Shore  Power 
Distribution 

-  Contract  Design 
Level  Design  Reports 

-  Inputs  for 
Specifications  as 
required 

-  Shipbuilding 
Specification 

-  DRL  deliverables 
such  as  Shipbuilder 
product  model 
outputs 

-  Shipbuilder  electric 
load  analysis  and 
system  diagrammatic 

C4ISR  (SWBS  400) 
and  Armament 
(SBWB  700) 

-  Notional  Equipment 
List 

-  Notional  Equipment 
List 

-  Notional  Equipment 
List 

-  Notional  Equipment 
List 

-  Equipment  List 

-  Parameter 
Accounting  Report 

-  Block  Diagrams 

-  Combat  Systems 
Arrangements 
Drawings 

-  Functional  Flow 
Diagrams  and 

Listings 

-  Specification 

-  Operational 
Sequence  Diagrams 

-  Software  Design 
and  Specification 
Documents 

DRL  Deliverables 
such  as  Shipbuilder 
Product  Model 
outputs  and  any 
Requirements  for 
Physical  or  Virtual 
Mockups  of  the 

Control  Spaces 
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Exploratory  Design 
and  Force 
Architecture 

Pre-AoA 

AoA 

Pre-Preliminary 

Preliminary 
(Functional  Baseline) 

Contract  (Allocated 
Baseline) 

Detail  (Product 
Baseline) 

Auxiliary  Systems 
(SWBS  500) 

-  System  Sizing  and 
Notional  Equipment 
Lists  as  required  for 
ship  arrangement 
and  weights 

-  System  Sizing  and 
Notional  Equipment 
Lists  as  required  for 
ship  arrangement 
and  weights 

-  System  Sizing  and 
Notional  Equipment 
Lists  as  required  for 
ship  arrangement 
and  weights 

-  Inputs  for 
Specifications  as 
required 

-  Preliminary  Design 
Level  Auxiliary 

System  Design 
Reports 

-  Sketches  for  boats, 
cargo,  and  vehicle 
stowage  and  handling 
systems 

-  Sketches  for 
anchor,  mooring, 
towed  body,  and 
over-the-side 
handling  systems 

-  Underway 
replenishment  system 
drawing 

-  Aviation  facilities 
drawings 

-  Inputs  for 
Specifications  as 
required 

-  Contract  Design 
Level  Design  Reports 

-  Inputs  for 
Specifications  as 
required 

-  Contract  Drawings, 
Guidance  Drawings 
or  PPDs  for  HVAC, 
Boats,  Aviation 
Facilities,  Underway 
Replenishment  and 
other  major  auxiliary 
systems 

-  Study  drawings  for 
other  major  auxiliary 
systems 

DRL  Deliverables 
such  as  Shipbuilder 
Product  Model 
outputs  and  System 
Technical  and  Test 
Reports 

Outfit  and  Furnishings 
(SWBS  600) 

FHabitability  Standards 
and  Outfit 
assumptions  that 
impact  arrangement 
and  weights 

FHabitability  Standards 
and  Outfit 
assumptions  that 
impact  arrangement 
and  weights 

-  FHabitability 

Standards  and  Outfit 
assumptions  that 
impact  arrangement 
and  weights 

-  Inputs  for 
Specifications  as 
required 

-  FHabitability 
Standards  and  Outfit 
assumptions  that 
impact  arrangement 
and  weights 

-  Hull  Outfitting 
Equipment  Study  to 
provide  inputs  for 
Specifications  as 
required 

-  Preliminary  Design 
level  Design  Reports 
for  Habitability, 
Workshops,  Medical 
and  other  major  outfit 
areas 

-  Inputs  for 
Specifications  as 
required 

-  Contract  Drawings, 
Guidance  Drawings 
or  PPDs  for 
Habitability, 
Workshops,  Medical 
and  other  major  outfit 
areas 

DRL  Deliverables 
such  as  Shipbuilder 
Product  Model 
outputs  and  System 
Technical  and  Test 
Reports 
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Exploratory  Design 
and  Force 
Architecture 

Pre-AoA 

AoA 

Pre-Preliminary 

Preliminary 
(Functional  Baseline) 

Contract  (Allocated 
Baseline) 

Detail  (Product 
Baseline) 

Corrosion  Control, 
Preservatives  and 
Covering  (SWBS 

630) 

-  Inputs  for 
Specifications  as 
required 

-  Corrosion 

Prevention  and 

Control  Plan  and 
Design  Report 

-  Conduct  Corrosion 
Prevention  Advisory 
Team 

-  Cathodic  Protection 
Study 

-  Input  for 
Specifications  as 
required 

-  Corrosion 

Prevention  and 

Control  Plan  and 
Design  Report 

-  Conduct  Corrosion 
Prevention  Advisory 
Team 

-  Input  for 
Specifications 

-  Shipbuilder 

Corrosion  Prevention 
and  Control  Plan 

-  Shipbuilder  conduct 
Corrosion  Prevention 
Advisory  Team 

-  DRL  Deliverables 
such  as  Shipbuilder 
Product  Model 
outputs 

-  Paint/Coating 
Schedules,  Data 
Sheets,  and 
Conformance 
Certifications 
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APPENDIX  Q 

SYSTEM  ENGINEERING  TECHNICAL  REVIEWS 

Table  Q-l.  SETR  and  Other  Reviews 


ASSESSMENT 

PURPOSE 

TIMING 

NOTE(S) 

Initial  Technical  Review  (ITR) 

Supports  the  technical  basis  for  initial  cost  estimates 
and  POM  submissions,  ICD  development,  and  AoA 
Guidance. 

Conducted  as  early  as  possible  for 
initial  program  planning. 

Alternative  Systems  Review 
(ASR) 

Reviews  results  of  the  Materiel  Solution  Analysis  Phase 
with  AoA  to  ensure  one  or  more  of  the  proposed 
materiel  solutions  have  the  potential  to  meet  the 
customer’s  needs  and  assess  planning  for  the 
Technology  Development  Phase. 

Conducted  near  the  end  of  the  AoA 
prior  to  Gate  2. 

Independent  Logistics 

Assessment  (ILA) 

Assesses  suitability  of  Logistics  planning. 

Prior  to  MS  B. 

System  Requirements  Review 
(SRR) 

Assesses  technical  readiness  for  CDD  submission  for 
Navy  staffing. 

Conducted  in  advance  of  submission  of 
the  CDD  for  initial  Navy  staffing  then 

Gate  3  and  in  advance  of  Milestone  A. 

System  Functional  Review  (SFR) 

Assesses  Functional  Baseline  and  readiness  to  begin 
functional  allocation. 

Conducted  during  Preliminary  Design  to 
verify  definition  of  the  Functional 

Baseline  in  advance  of  Gate  4. 

Preliminary  Design  Review  (PDR) 

Assesses  Allocated  Baseline  and  readiness  to  begin 
Detail  Design. 

Conducted  during  late  Contract  Design 
prior  to  Milestone  B  or  early  in  Detail 
Design  following  Milestone  B. 

Critical  Design  Review  (CDR) 

Assesses  Product  Baseline  and  Supports  Production 
Readiness  Review. 

Conducted  in  mid  to  late  Detail  Design. 
May  or  may  not  be  combined  with  PRR. 
May  support  Gate  6. 

Integrated  Baseline  Review  (IBR) 

Assesses  risk  areas  in  contract.  Produces  Performance 
Measurement  Baseline  to  ensure  technical  scope  of 
work  is  realistically  and  accurately  scheduled,  has 
proper  resources,  utilizes  correct  techniques,  and 
employs  appropriate  management  processes. 

Prior  to  start  of  DD&C. 

1 

Functional  Configuration  Audit 
(FCA) 

Assesses  whether  necessary  analyses  and  tests  have 
been  completed  to  assure  system  compliance  with 
Functional  Baseline. 

Conducted  in  late  Detail  Design  just 
prior  to  beginning  production.  May 
support  Gate  6. 

2 

System  Verification  Review  (SVR) 

Assesses  system  compliance  with  Functional  Baseline. 

Conducted  in  late  Detail  Design  just 
prior  to  beginning  production.  May 
support  Gate  6. 

2 

Production  Readiness  Review 
(PRR) 

Assesses  system  readiness  to  enter  production. 

Conducted  in  late  Detail  Design  just 
prior  to  beginning  production.  May 
support  Gate  6. 

2,3 
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ASSESSMENT 

PURPOSE 

TIMING 

NOTE(S) 

Sustainment  Review  1 

Assess  Shipbuilder  progress  in  logistics 
planning  &  documentation. 

After  DD&C  Award. 

4 

Sustainment  Review  II 

Assess  Shipbuilder  progress  in  logistics 
planning  &  documentation. 

Two  years  After  Sustainment  Review  1. 

4 

Test  Readiness  Review  (TRR) 

Assesses  system  readiness  to  begin 
Developmental  Test  and  Evaluation 
(DT&E). 

During  early  DD&C  phase. 

Integrated  Readiness  Review 
(IRR) 

Assesses  readiness  of  software  systems. 

In  Contract  Design  to  assess  progress  of 
development  of  software  specifications. 

Operational  Test  Readiness 
Review  (OTRR) 

Assesses  system  readiness  to  proceed  into 
Operational  Test  and  Evaluation  (OT&E) 
with  high  likelihood  of  success. 

Prior  to  OPEVAL. 

In-Service  Review  (ISR) 

Assesses  the  in-service  technical  health  of 
a  fielded  system  from  a  risk,  readiness,  and 
resources  perspective.  Assesses  lead 
ship’s  demonstrated  capability  to  meet 
customer’s  need. 

Following  lead  ship  initial  deployment 
Conducted  following  lead  ship  Initial 
Operational  Capability  or  deployment.  May 
support  Milestone  C  and/or  FRP  DR  and  a 
Gate  6. 

Notes: 

1 .  A  requirement  for  event -based  design,  program,  and  sustainment  reviews  will  be  incorporated  into  the  DD&C  contract.  In-process  design 
reviews  shall  be  held  during  Detail  Design. 

2.  SVR,  PRR,  &  FCA  are  conducted  as  parts  of  one  consolidated  Review. 

3.  SPPCs  shall  be  conducted  following  the  PRR. 

4.  The  Sustainment  Review  will  be  Program  Manager-chaired  to  assess  Shipbuilder  progress  in  the  logistics  planning  and  documentation 
development  required  to  support  life  cycle  logistics.  These  will  be  preceded  by  a  series  of  regularly  scheduled  working  level  status 
meetings.  Development  and  delivery  for  logistics  documentation  by  the  Shipbuilder  are  provided  for  in  the  DD&C  Statement  of  Work, 
System  Specification  and  subsequent  Shipbuilding  Specification,  and  Data  Requirements  List  (DRL).  This  includes  the  regulatory  body 
certifications,  equipment  logistics  support  information  packages,  recommended  shore  based  spares,  technical  manuals,  damage  control 
book,  selected  record  drawings,  and  other  information  for  ships  operations,  maintenance,  and  upgrade. 
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Table  Q-2.  SETR  Roles 


ITR,  ASR,  SRR,  SFR 

PDR,  CDR 

SVR/FCA/PRR 

In-Service 

Reviews 

Responsibility, 
Authority,  and 
Accountability 

SEA  05D  and  the  Program  Office  supported 
by  the  SDM  determine  whether  the  entry 
criteria  have  been  met,  what  action  items  are 
to  be  tasked,  that  tasked  items  have  been 
closed  appropriately,  that  exit  criteria  have 
been  met,  and  sign  any  resulting  reports. 

Same  as  in  preceding 
column. 

Same  as  in 
preceding  column. 

Same  as  in 
preceding  column 
with  addition  of 

Life  Cycle 

Program 

Manager  and 

SDM. 

Chairperson 

SEA  05D  DWO  serving  as  a  Peer  Review  or 
more  formal  Technical  Review  Board 
(TRB)/Stakeholder  Steering  Board  (SSB) 

Chair  and  supported  by  the  SDM  as  the 
Program  Lead  Systems  Engineer  (LSE). 

Program  Manager  or  his 
representative  supported  by 
the  SDM  as  the  SEA  05D 

DWO  representative  and 

LSE. 

Same  as  in 
preceding  column. 

Procurement  and 
Life  Cycle 

Program 

Managers. 

Program 

Management 

Office  Participants 

Principal  Acquisition  Program  Manager, 
Acquisition  Program  Manager,  Test  and 
Evaluation  Manager,  Logistics  Manager, 
Contracting  Officer(if  contracting  issues  will  be 
discussed),  Counsel  (if  legal  issues  will  be 
discussed),  Design  Team  leads,  Cost  Team 
representative. 

Same  as  in  preceding 
column. 

Same  as  in 
preceding  column 
plus  the  Program 
Manager’s 
Representative  at 
the  Shipbuilder. 

Same  as  in 

preceding 

column. 

Anticipated 

Stakeholder 

Organizations 

Resource  Sponsor  representatives,  User 
Organization. 

Same  as  in  preceding  column 
plus  representatives  from 
COMOPTEVFOR,  DoD 

DOT&E,  OSD/DDT&E,  OSD 
SE,  and  ASN  RDA  CHENG 
as  appropriate  for  Program 

AC  AT. 

Same  as  in 
preceding  column 
plus 

representatives 
from  the  Supervisor 
of  Shipbuilding  and 
possibly  the 
Shipbuilder. 

Same  as  in 

preceding 

column. 

Anticipated  Peer 
and  Program- 
Independent 

Subject  Matter 
Expert  Participant 
Organizations 

Applicable  TWHs. 

Same  as  in  preceding 
column. 

Same  as  in 
preceding  column. 

Same  as  in 

preceding 

column. 
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Entrance  criteria  for  each  review  are  summarized  in  the  table  below.  The  Exit  Criteria  are  qualitative  assessments  of  design  maturity  and  for  their 
corresponding  Entrance  Criteria  represent  a  determination  that: 

•  Accomplished  work  submitted  as  Entrance  Criteria  is  of  sufficient  quality,  completeness,  and  maturity  to  warrant  moving  forward  to  the 
next  phase. 

•  The  prevailing  risks  are  acceptable  and/or  manageable. 

Table  Q-3.  SETR  Entrance/Exit  Criteria 


ITR 

ASR 

SRR 

SFR 

PDR 

CDR 

SVR/FCA/  PRR 

In-Service 

Reviews 

Overall  Design  Status 

Action  items 
from  prior 
internal  and 
external 
reviews  have 
been 

completed  or  a 
plan 

established  to 
complete  them. 

Not  applicable  - 
no  prior  reviews. 

SDM  tracks. 

SDM  tracks. 

SDM  tracks. 

SDM  tracks. 

SDM  tracks. 

SDM  tracks. 

Procurement  and 
Life  Cycle  SDMs 
track. 

Design  efforts 
have  been 
conducted  in 
accordance 
with  current 
design  phase 
Design  Team 
Engineering 
Management 

Plan  (EMP) 
including 
involvement  of 
appropriate 
TWHs  and 
other 

stakeholders. 

CBA  whole  ship 
concept  design 
Development  of 
EMP  beginning. 

Updated  as 
required  in 

Design  Team 

EMP.  Input  for 
Program  SEP. 

Updated  as 
required  in 

Design  Team 

EMP.  Input  for 
Program  SEP. 

Updated  as 
required  in 

Design  Team 

EMP.  Input  for 
Program  SEP. 

Updated  as 
required  in 

Design  Team 

EMP.  Input  for 
Program  SEP. 

Updated  as 
required  in 

Design  Team 

EMP.  Input  for 
Program  SEP. 

Updated  as 
required  in 

Design  Team 

EMP.  Input  for 
Program  SEP. 

Updated  as 
required  in 
Production  and 

Life  Cycle  Design 
Teams'  EMPs. 

Input  for  Program 
SEP. 
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ITR 

ASR 

SRR 

SFR 

PDR 

CDR 

SVR/FCA/  PRR 

In-Service 

Reviews 

Design  scope 
has  been 
appropriate  for 
the  design 
phase. 

CBA  whole  ship 
concept  design. 

Whole  ship 
concept  designs, 
system  trade 
studies,  white 
papers  defining 
AoA  materiel 
solution(s). 

Pre-Preliminary 

Design 

supporting  CDD 
finalization  and 
cost  estimating. 

Preliminary 

Design  sufficient 
to  establish 
Functional 
Baseline. 

Contract  Design 
sufficient  to 
establish 

Allocated 

Baseline. 

Detail  Design 
sufficient  to 
establish  Product 
Baseline. 

Detail  Design 
sufficient  to 
support  start  of 
construction. 

Ongoing 

Production 
Engineering 
Changes  and 

Fleet 

Modernization 

Program 

SHIPALTs  are 
receiving 
engineering 
review. 

Design 

considerations/ 

specialty 

engineering 

approaches 

appropriate  for 

the  phase  have 

been 

addressed. 

Limited  to  those 
supporting  whole 
ship  concept 
design  and 
procurement  and 
life  cycle  costing. 

Limited  to  those 
supporting 
concept  design 
and  procurement 
and  life  cycle 
costing. 

Limited  to  those 
supporting  Pre- 
Preliminary 

Design 

supporting  CDD 
finalization  and 
cost  estimating. 
Begins  to 
address  all  areas 
forSDS. 

Focuses  on 
those  for  ship 
sizing  and 
budgeting  for 
Preliminary 
design  but 
addresses  all 
areas  for  Ship 
Specification. 

Covers  all  areas 
applicable  to  the 
ship  class. 

Covers  all  areas 
applicable  to  the 
ship  class. 

Covers  all  areas 
applicable  to  the 
ship  class. 

Covers  all  areas 
applicable  to  the 
ship  class. 

Design 

products  are 

complete, 

reviewed, 

adequate, 

under 

configuration 
control,  and 
provide  a 
suitable 
baseline  to 
proceed  to  the 
next  phase. 

CBA  whole  ship 
concept  design, 
system  trade 
studies. 

Whole  ship 
concept  design, 
system  trade 
studies,  white 
papers. 

Pre-Preliminary 
Design  products. 

Preliminary 

Design  products 
that  comprise  the 
Functional 
Baseline. 

Contract  Design 
products  that 
comprise  the 
Allocated 

Baseline. 

Detail  Design 
products  that 
comprise  the 
Product  Baseline. 

Detail  Design 

products 

supporting 

construction 

startup. 

Product  Baseline 
with  ongoing 
Engineering 
Changes  and 
SHIPALTs. 

Technical 
Performance 
Measures 
(TPMs)  have 
been 

established 
and  are  on 
track. 

Defined  in  draft 
EMP. 

Updated  as 
required  in 

Design  Team 

EMP.  Input  for 
Program  SEP. 

Updated  as 
required  in 

Design  Team 

EMP.  Input  for 
Program  SEP. 

Updated  as 
required  in 

Design  Team 

EMP.  Input  for 
Program  SEP. 

Updated  as 
required  in 

Design  Team 

EMP.  Input  for 
Program  SEP. 

Updated  as 
required  in 

Design  Team 

EMP.  Input  for 
Program  SEP. 

Updated  as 
required  in 

Design  Team 

EMP.  Input  for 
Program  SEP. 

Updated  as 
required  in 
Production  and 

Life  Cycle  Design 
Teams'  EMPs. 

Input  for  Program 
SEP. 
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ITR 

ASR 

SRR 

SFR 

PDR 

CDR 

SVR/FCA/  PRR 

In-Service 

Reviews 

Design  budgets 
are  established 
and  the  design 
is  within 
budget. 

Not  applicable. 

Updated  as 
required  in 

Design  Team 

EMP.  Input  for 
Program  SEP. 

Updated  as 
required  in 

Design  Team 

EMP.  Input  for 
Program  SEP. 

Updated  as 
required  in 

Design  Team 

EMP.  Input  for 
Program  SEP. 

Updated  as 
required  in 

Design  Team 

EMP.  Input  for 
Program  SEP. 

Updated  as 
required  in 

Design  Team 

EMP.  Input  for 
Program  SEP. 

Updated  as 
required  in 

Design  Team 

EMP.  Input  for 
Program  SEP. 

Engineering 
Change  and 
SHIPALTcost 
estimates. 

Basis  for  the 
cost  estimates 
are  defined  in  a 
CARD  like 
document. 
Assumptions 
are  fully 
defined  and  are 
executable. 

Risks  are 
described  and 
are 

manageable. 

Cost  forms 
provided  to  SEA 
05C  provide 
basis.  Initial  risk 
assessment. 

Cost  forms 
provided  to  SEA 
05C  provide 
basis.  Initial  Risk 
Register. 

Cost  forms 
provided  to  SEA 
05C  provide 
basis  and  CARD 
developed  for 
Milestone  A. 
Updated  Risk 
Register. 

Cost  forms 
provided  to  SEA 
05C  provide 
basis.  Updated 

Risk  Register. 

Cost  forms 
provided  to  SEA 
05C  provide 
basis  and  CARD 
developed  for 
Milestone  B. 
Updated  Risk 
Register. 

Shipbuilder  cost 
reports.  Updated 
Program  Risk 
Register. 
Shipbuilder  risk 
assessments. 

Shipbuilder  cost 
reports.  Updated 
Program  Risk 
Register. 
Shipbuilder  risk 
assessments. 

Shipbuilder  cost 
reports. 

Engineering 
Change  and 
SHIPALT  costs. 
Updated 

Program  Risk 
Register. 
Shipbuilder  risk 
assessments. 

Cost  estimates 
have  been 
completed  and 
an  independent 
assessment 
obtained. 

SEA  05C 
performs  cost 
estimates  for 
whole  ship 
concept  designs. 
Service  Cost 
position  to  be 
developed 
following  AoA. 

SEA  05C 
performs  cost 
estimates  for 
whole  ship 
concept  designs. 
Service  Cost 
position 
developed. 

SEA  05C 
performs  cost 
estimates  for 
Pre-Preliminary 
Design.  Service 
Cost  position 
developed. 
Independent 

Cost  Estimate 
performed  for  MS 
A. 

SEA  05C 
performs  cost 
estimates  for 
whole  ship 
concept  designs. 
Service  Cost 
position 
developed. 

SEA  05C 
performs  cost 
estimates  for 
whole  ship 
concept  designs. 
Service  Cost 
position 
developed. 
Independent 

Cost  Estimate 
performed  for  MS 

B. 

Service  Cost 

position 

developed/ 

maintained 

based  on 

Shipbuilder  cost 

reports. 

Service  Cost 

position 

developed/ 

maintained 

based  on 

Shipbuilder  cost 

reports. 

Service  Cost 
position 
developed/ 
maintained 
based  on 
Shipbuilder  cost 
reports  and 
projected  Fleet 
Modernization 
costs. 

CAIV  targets 
are  defined  and 
can  be  met. 

Cost  estimates 
provide  basis  for 
draft  ICD  and 

AoA  Guidance 
content  which  is 
documented  with 
rationale. 

AoA  materiel 
solution  cost 
estimates  are 
used  to  continue 
to  refine  and 
validate. 

Pre-Preliminary 
Design  cost 
estimates  provide 
basis  for  draft 

CDD  cost 
threshold/ 
objective  content. 
ICE  for  MSA 
also  confirms. 

Preliminary 

Design  cost 
estimates 
validate  that 
design  meets 

CDD  cost 

thresholds/ 

objectives. 

Preliminary 

Design  cost 
estimates 
validate  that 
design  meets 

CDD  cost 
thresholds/ 
objectives.  ICE 
for  MS  B  also 
confirms. 

Program  tracks 

Shipbuilder 

costs. 

Program  tracks 

Shipbuilder 

costs. 

Production 

Program  tracks 
Shipbuilder 
costs.  Life  Cycle 
Program  tracks 
Fleet 

Modernization 

costs. 
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CDR 
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In-Service 

Reviews 

Design  efforts 
are  supporting 
maintenance  of 
the  Program’s 
critical  path. 

Initial  Design 

PowerPoint 

schedule 

integrated  with 

Program 

milestones. 

Initial  Design 
Microsoft  Project 
or  equivalent 
schedule 
integrated  with 
Program 
milestones. 

Full  Program 
Microsoft  Project 
or  equivalent 
schedule 
including  Design. 

Full  Program 
Microsoft  Project 
or  equivalent 
schedule 
including  Design. 

Full  Program 
Microsoft  Project 
or  equivalent 
schedule 
including  Design. 

Design  Team 
and  Program 
oversight  of  the 
Shipbuilder’s 
schedule. 

Design  Team 
and  Program 
oversight  of  the 
Shipbuilder’s 
schedule. 

Design  Team 
and  Program 
oversight  of  the 
Shipbuilder’s 
schedule. 

Shipbuilder 
EVMS  trends 
are  on  track 
including 
drawing/design 
data  releases. 

Program  tracks 
Shipbuilder 

EVMS  trends. 

Program  tracks 
Shipbuilder 

EVMS  trends. 

Program  tracks 
Shipbuilder 

EVMS  trends. 

Design  issues 
have  been 
resolved 
sufficiently  to 
permit 

proceeding  to 
the  next  design 
phase. 

SDM  tracks. 

SDM  tracks. 

SDM  tracks. 

SDM  tracks. 

SDM  tracks. 

SDM  tracks. 

SDM  tracks. 

Production  and 

Life  Cycle  SDMs 
track. 

Requirements,  Specification,  Test  and  Evaluation 

Scenarios, 

Threat  Sets, 
CONOPS  and 
Design 

Reference 
Mission  (DRM) 
has  been 
defined  and 
validated 
through  design 
process. 

Draft  Scenarios, 
Threat  Sets, 
CONOPS  in  ICD 
and  DRM  being 
developed  for 

AoA. 

Scenarios, 

Threat  Sets, 
CONOPS  and 

DRM  update  as 
required. 

Scenarios, 

Threat  Sets, 
CONOPS  and 

DRM  update  as 
required. 

Scenarios, 

Threat  Sets, 
CONOPS  and 

DRM  update  as 
required. 

Scenarios, 

Threat  Sets, 
CONOPS  and 

DRM  update  as 
required. 

Scenarios, 

Threat  Sets, 
CONOPS  and 

DRM  update  as 
required. 

Scenarios, 

Threat  Sets, 
CONOPS  and 

DRM  update  as 
required  based 
on  operational 
experience. 

S9800-AC-MAN-01 0 


Q-8 


ITR 

ASR 

SRR 
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CDR 

SVR/FCA/  PRR 

In-Service 

Reviews 

Design  efforts 
support 
definition  of 
proposed 

Materiel 

Solution(s) 

CBA  whole  ship 
concept  design, 
system  trade 
studies,  white 
papers  support 
development  of 
material  solutions 
for  ICD  and  AoA 
Guidance. 

Whole  ship 
concept  design, 
system  trade 
studies,  white 
papers  support 

AoA  definition  of 
proposed 
materiel  solution. 

Requirements 
are  defined, 
verifiable, 
traceable,  and 
under 

configuration 
control  with 
supporting 
analysis. 

Draft  ICD  and 

AoA  Guidance 
content  are 
documented  with 
rationale. 

Development  of 
content  for  CDD 
begins  in 
conjunction  with 
completion  of  the 
AoA  and  to  be 
addressed  at 

Gate  2. 

CDD  is  ready  for 
Navy  staffing  and 
SDS  Plan  is 
prepared  to 
support  Gate  3. 

CDD  is  approved 
and  SDS  is  ready 
for  approval  to 
support  Ship 
Specification 
development. 
Requirements 
traceability  from 
the  CDD  has 
started. 

Ship 

Specification  is 
being  finalized 
with 

requirements 
traceability  from 
CDD 

demonstrated. 

Traceability  from 
the  CDD  to  Ship 
Specification  to 
Shipbuilding 
Specification  (if 
applicable)  is 
confirmed. 

CDD  update  or 
CPD 

development  and 
staffing  as 
required. 

CDD  update  or 
CPD 

development  and 
staffing  as 
required. 

Design  efforts 
support 
fulfillment  of 
the  user’s 
requirements. 

Alternative 
materiel 
solution(s) 
developed  to 
meet  user  needs. 

Proposed 

materiel 

solution(s)  satisfy 
user  needs. 

Pre-Preliminary 
Design  validates 
draft  CDD 
content  which 
reflects  user 
requirements. 

Preliminary 

Design  validates 
CDD  content 
which  reflects 

user 

requirements. 

Contract  Design 
validates  CDD 
content  which 
reflects  user 
requirements. 

Operational 
experience 
validates  CDD 
content  which 
reflects  user 
requirements. 

Work 

Breakdown 
Structure  has 
been 

established. 

Being  defined  in 
draft  SEP. 

Updated  as 
required  in  SEP. 

Updated  as 
required  in  SEP. 

Updated  as 
required  in  SEP. 

Updated  as 
required  in  SEP. 

Updated  as 
required  in  SEP. 

Updated  as 
required  in  SEP. 

Updated  as 
required  in  SEP. 

Systems  and 
software 
architectures 
have  been 
defined  and 
validated  by 
design 
process. 

Being  defined  in 
draft  SEP. 

Updated  as 
required  in  SEP. 

Updated  as 
required  in  SEP. 

Updated  as 
required  in  SEP. 

Updated  as 
required  in  SEP. 

Updated  as 
required  in  SEP. 

Updated  as 
required  in  SEP. 

Updated  as 
required  in  SEP. 
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CDR 

SVR/FCA/  PRR 

In-Service 

Reviews 

System  Design 
Specification 
(SDS)  has  been 
developed. 

SDS  Plan  for 

Gate  3. 

SDS  for  Gate  4. 

Ship 

Specification 
has  been 
developed  and 
validated 
through  the 
design 
process. 

Ship 

Specification 
development  is 
beginning. 

Ship 

Specification  is 
ready  for 
finalization. 

Ongoing 
production  and 
lead  ship 
operational 
feedback  for  Ship 
Specification 
updates. 

Physical  and 
functional 
interfaces  and 
standards  are 
defined. 

SDS  addresses. 

Ship 

Specification 

addresses. 

Ship 

Specification 

addresses. 

Ongoing 
production  and 
lead  ship 
operational 
feedback  for  Ship 
Specification 
updates. 

Verification 
methods  and 
standards  are 
defined. 

SDS  addresses. 

Ship 

Specification 

addresses. 

System  or 
Shipbuilder 
Specification 
addresses. 

Ongoing 
production  and 
lead  ship 
operational 
feedback  for  Ship 
Specification 
updates. 

Certification 
requirements 
are  defined. 

Being  defined  in 
draft  SEP. 

Updated  as 
required  in  SEP. 

Updated  as 
required  in  SEP. 

SEP  and  SDS 
address. 

SEP  and  Ship 

Specification 

address. 

SEP  and  System 
or  Shipbuilder 
Specification 
address. 

Ongoing 
production  and 
lead  ship 
operational 
feedback  for  Ship 
Specification 
updates. 
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CDR 

SVR/FCA/  PRR 

In-Service 

Reviews 

Design  Considerations 

Technology 
readiness  has 
been  assessed 
and  is 

appropriate  to 
the  phase. 

Draft  ICD,  AoA 
Guidance,  initial 
risk  assessment 
address. 

Address  for  Gate 

2. 

CDD  describes. 
Technical 
Readiness 
Assessment  and 
TDS/AS  for  MS  A 
addresses. 

Address  for  Gate 

4. 

Technical 
Readiness 
Assessment  and 
AS  for  MS  B 
addresses. 

Updated 

Technical 
Readiness 
Assessment  and 
AS  for  MS  C 
and/or  FRP  DR 
addresses. 

Master 

Equipment  List 
Items  are 
defined  at  the 
component 
level. 

Design 

deliverable. 

Design 

deliverable. 

Design 

deliverable. 

Design 

deliverable. 

Software 

requirements, 

design,  and 

sustainment/su 

pportability 

approach  is 

established. 

SEP  addresses. 

SEP  and  SDS 
address. 

SEP,  Life  Cycle 
Sustainment 

Plan,  and  Ship 

Specification 

address. 

SEP,  Life  Cycle 
Sustainment 

Plan,  and  Ship 

Specification 

address. 

Ongoing 
production  and 
lead  ship 
operational 
feedback  for  Ship 
Specification 
updates. 

Life  cycle 
supportability/ 
sustainment 
approach  has 
been  defined. 

SEP  and  TDS/AS 
addresses. 

SEP,  AS  and 

SDS  address. 

Life  Cycle 
Sustainment 

Plan,  SEP,  AS 
and  Ship 
Specification 
address. 

Life  Cycle 
Sustainment 

Plan,  SEP,  AS 
and  System  or 
Shipbuilder 
Specification 
address. 

Ongoing 
production  and 
lead  ship 
operational 
feedback  for  Ship 
Specification 
updates. 

Reliability, 

Availability, 

Maintainability 

-  Cost  (RAM-C) 

requirements 

are 

documented 
and  verified. 

Draft  ICD  and 

AoA  Guidance 
content 

documented  with 
rationale  based 
on  DRM  and 
initial  RAM-C 
analysis. 

RAM-C  analysis 
for  materiel 
alternatives  (if  an 
AoA 

discriminator). 

RAM-C  Report 
with  content 
forming  the  basis 
of  the  RAM 
requirements  for 
the  CDD. 

RAM-C  Report 
update  as 
required  with 
content  forming 
the  basis  of  the 
RAM 

requirements  for 
the  Ship 
Specification. 

Oversight  of 
Shipbuilder 
compliance  with 
RAM 

requirement. 

Ongoing 
production  and 
lead  ship 
operational 
feedback  for  Ship 
Specification 
updates. 
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Assessment  of 
the  risk  of 
using  COTS  is 
accomplished. 

SEP  addresses. 

SEP  and  SDS 
address. 

Life  Cycle 
Sustainment 

Plan,  SEP  and 

Ship 

Specification 

address. 

SEP  and  Ship 

Specification 

address. 

SEP  and  System 
or  Shipbuilder 
Specification 
address. 

Ongoing 
production  and 
lead  ship 
operational 
feedback  for  Ship 
Specification 
updates. 

Open  Systems 
Approach  is 
defined. 

SEP  addresses. 

SEP  and  SDS 
address. 

Life  Cycle 
Sustainment 

Plan,  SEP  and 

Ship 

Specification 

address. 

SEP  and  Ship 

Specification 

address. 

SEP  and  Ship 

Specification 

address. 

Ongoing 
production  and 
lead  ship 
operational 
feedback  for  Ship 
Specification 
updates. 

Hardware, 
software,  and 
human 
interface 
compatibility  is 
confirmed. 

Draft  ICD  and 

AoA  Guidance 
content 

documented  with 
rationale. 

Concept  design 
level  analysis. 

Concept  design 
level  analysis. 

CDD  and  SDS 
address.  Pre- 
Preliminary 

Design  level 
analysis. 

Ship 

Specification 

addresses. 

Preliminary 

Design  level 
analysis. 

HSI  Plan  and 

Ship 

Specification 

address. 

Contract  Design 
level  analysis. 

HSI  Plan  and 

Ship 

Specification 
address.  Detail 
Design  level 
analysis. 

Ongoing 
production  and 
lead  ship 
operational 
feedback  for  Ship 
Specification 
updates. 

Human  job  and 
task  analysis  is 
sufficient  to 
provide  crew 
workload,  skill 
level,  and  total 
ship 

accommodatio 

ns. 

Draft  ICD  and 

AoA  Guidance 
content 

documented  with 
rationale. 

Concept  design 
level  analysis. 

Concept  design 
level  analysis. 

CDD  Pre- 
Preliminary 

Design  level 
analysis. 

Ship 

Specification 

addresses. 

Preliminary 

Design  level 
analysis. 

Navy  Training 
Systems  Plan 
and  Ship 
Specification 
address. 

Contract  Design 
level  analysis. 

Navy  Training 
System  Plan  and 
System  or 
Shipbuilder 
Specification 
address.  Detail 
Design  level 
analysis. 

Ongoing 
production  and 
lead  ship 
operational 
feedback  for  Ship 
Specification 
updates. 

Environmental, 
occupational 
safety,  and 
health 
compliance 
factors  have 
been  assessed 
and  issues 
documented. 

Draft  ICD  and 

AoA  Guidance 
content 

documented  with 
rationale. 

Concept  design 
level  analysis. 

Concept  design 
level  analysis. 

CDD  and  SDS 
address.  Pre- 
Preliminary 

Design  level 
analysis. 

Ship 

Specification 

addresses. 

Preliminary 

Design  level 
analysis. 

PESHE  and  Ship 

Specification 

address. 

Contract  Design 
level  analysis. 

PESHE  and 
System  or 
Shipbuilder 
Specification 
address.  Detail 
Design  level 
analysis. 

Ongoing 
production  and 
lead  ship 
operational 
feedback  for  Ship 
Specification 
updates. 
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ABS 

Classification 
Assessment  is 
complete  and 
any  critical 
issues  have 
been 

satisfactorily 

addressed. 

Initial 

identification/ 
assessment  of 
potential  issues. 

Initial 

identification/ass 
essment  of 
potential  issues. 

Initial 

identification/ass 
essment  of 
potential  issues. 

Preliminary 

Design  level 
assessment. 

Contract  Design 
level 

assessment. 

Detail  Design 
level 

assessment. 

ABS 

Classification 
Assessment  as 
required  for 
Production 
Engineering 
Changes  and 

Fleet 

Modernization 

SHIPALTs. 

Industrial  Base/Manufacturing  Readiness 

Design 
approach  is 
producible  with 
acceptable  risk. 

Concept  Design 
level  of  analysis. 

Concept  Design 
level  of  analysis. 

Pre-Preliminary 
Design  level  of 
analysis. 

Preliminary 

Design  level  of 
analysis. 

Contract  Design 
level  of  analysis. 

Detail  Design 
level  of  analysis. 

Assess 

Production 

Engineering 

Changes. 

Manufacturing 

Readiness 

Level  has  been 
assessed  and 
documented. 

Assessed  and 
documented  in 

AS  and  SEP  for 

MS  B. 

Updated 
Manufacturing 
Readiness 
Assessment  in 

AS  for  MS  C 
and/or  FRP  DR 
addresses. 

Manufacturing 
facilities  are 
sufficient  and 
prepared. 

Part  of  Industrial 
Base 

assessment  in 
TDS/AS  and 
Program  Health 
assessment. 

Part  of  Industrial 
Base 

assessment  in 

AS  and  Program 

Health 

assessment. 

Part  of  Industrial 
Base 

assessment  in 

AS  and  Program 

Health 

assessment. 

Part  of  Industrial 
Base 

assessment  in 

AS  and  Program 

Health 

assessment. 

Shipbuilder  work 

performance 

information. 

Shipbuilder  work 

performance 

information. 

Shipbuilder 
staffing  is 
adequate. 

Shipbuilder  work 

performance 

information. 

Shipbuilder  work 

performance 

information. 

Long  lead 
items  are 
identified  and 
planned  for 
early 

procurement. 

Pre-Preliminary 
Design  level  of 
analysis. 

Addressed  in  AS. 

Preliminary 

Design  level  of 
analysis. 

Addressed  in  AS. 

Contract  Design 
level  of  analysis. 
Addressed  in  AS 
and  RFP. 

Detail  Design 
level  of  analysis. 
Addressed  in  AS 
and  contract. 
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Production 
schedule  is  in 
place  and 
meets  Program 
schedule 
requirements. 

Schedule  is  in 
draft  and 
demonstrates 
production 
preparations  are 
on  track. 

Schedule  is 
finalized  and 
demonstrates 
Shipbuilder  is 
ready  to  begin 
production. 

Material  and 
equipment 
ordering 
processes  are 
in  place  and 
ordering  on 
track. 

Materiel 
equipment  and 
ordering 

processes  are  in 
place  and 
ordering  on  track 
to  support 
production. 

Materiel  ordering 
is  on  track  to 
support 
production. 

Design 
drawings  and 
other 

configuration 
data  exist  to 
support 
production 
startup. 

Shipbuilder  work 
performance 
information 
demonstrates 
sufficient  drawing 
and  work 
package 
completions. 

Shipbuilder  work 
performance 
information 
demonstrates 
sufficient  drawing 
and  work 
package 
completions. 

Planning  for  Next  Design  Phase 

Design  Team 

Engineering 

Management 

Plan  has  been 
developed  for 
next  phase  and 
inputs  provided 
for  Program 

SEP. 

Design  Team 

EMP  to  support 
AoA  conduct. 

Updated  Design 
Team  EMP  to 
support  next 
phase.  Inputs  for 
MS  A  SEP. 

Updated  Design 
Team  EMP  to 
support  next 
phase.  Inputs  for 
MS  A  SEP. 

Updated  Design 
Team  EMP  to 
support  next 
phase.  Inputs  for 
MS  B  SEP. 

Updated  Design 
Team  EMP  to 
support  next 
phase.  Inputs  for 
MS  B  SEP. 

Updated  Design 
Team  EMP  to 
support  next 
phase.  Inputs  for 
MS  C/FRP  DR 
SEP. 

Updated  Design 
Team  EMP  to 
support  next 
phase.  Inputs  for 
MS  C/FRP  DR 
SEP. 

Updated 

Production  and 
Design  Teams’ 
EMPs.  Inputs  for 
MS  C/FRP  DR 
SEP. 

Integrated 

Master 

Schedule  has 
been 

developed  and 
is  being 
employed  to 
track  progress. 

Initial  Design 

PowerPoint 

schedule 

integrated  with 

Program 

milestones. 

Initial  Design 
Microsoft  Project 
or  equivalent 
schedule 
integrated  with 
Program 
milestones. 

Full  Program 
Microsoft  Project 
or  equivalent 
schedule 
including  Design. 

Full  Program 
Microsoft  Project 
or  equivalent 
schedule 
including  Design. 

Full  Program 
Microsoft  Project 
or  equivalent 
schedule 
including  Design. 

Design  Team 
and  Program 
oversight  of  the 
Shipbuilder’s 
schedule. 

Design  Team 
and  Program 
oversight  of  the 
Shipbuilder’s 
schedule. 

Production 

Design  Team 
and  Program 
oversight  of  the 
Shipbuilder’s 
schedule.  Life 

Cycle  Program 
oversight  of  Fleet 
Modernization. 
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Planning  for 
upcoming 
Modeling  and 
Simulation  is 
complete 
including 

VV&A. 

Address 
requirement  in 
Design  Team 

EMP  and 

Program  SEP 
and  develop 
separate  plans  if 
M&S  required. 

Address 
requirement  in 
Design  Team 

EMP  and 

Program  SEP 
and  develop 
separate  plans  if 
M&S  required. 

Address 
requirement  in 
Design  Team 

EMP  and 

Program  SEP 
and  develop 
separate  plans  if 
M&S  required. 

Address 
requirement  in 
Design  Team 

EMP  and 

Program  SEP 
and  develop 
separate  plans  if 
M&S  required. 

Address 
requirement  in 
Design  Team 

EMP  and 

Program  SEP 
and  develop 
separate  plans  if 
M&S  required. 

Address 
requirement  in 
Design  Team 

EMP  and 

Program  SEP 
and  develop 
separate  plans  if 
M&S  required. 

Address 
requirement  in 
Design  Team 

EMP  and 

Program  SEP 
and  develop 
separate  plans  if 
M&S  required. 

Planning  for 
competitive 
prototyping  is 
complete. 

Address  in 

Program  TDS/AS 
for  MS  A  and 
reflect  in  Design 
Team  EMP  and 
Program  SEP. 

Address  in 

Program  TDS/AS 
for  MS  A  and 
reflect  in  Design 
Team  EMP  and 
Program  SEP. 

Update  in 

Program  AS  for 

MS  B  and  reflect 
in  Design  Team 
EMP  and 

Program  SEP. 

Update  in 

Program  AS  for 

MS  B  and  reflect 
in  Design  Team 
EMP  and 

Program  SEP. 

Update  in 

Program  AS  for 

MS  C/FRP  DR 
and  reflect  in 
Design  Team 

EMP  and 

Program  SEP. 

Update  in 

Program  AS  for 

MS  C/FRP  DR 
and  reflect  in 
Design  Team 

EMP  and 

Program  SEP. 

Flow  down  of 
design  results 
into  Milestone 
and  other 
program 
documents. 

For  MDD. 

For  MS  A. 

For  MS  A. 

For  MS  B. 

For  MS  B. 

For  MS 

C/FRPDR. 

For  MS 

C/FRPDR. 
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Risk  Management  and  Program  Health 

Risk  mitigation 
plans  are 
developed  and 
assessments 
are  being 
conducted. 

Risk  mitigation 
activities  for 
high  risk  items 
are  planned 
and  funded. 

Initial  risk 
assessment  and 
associated 
mitigation 
planning. 

Full  assessment 
of  all  areas 
including 
technological 
maturity  and 
system  safety. 

Initial  Risk 

Register. 

Updated 
assessment  and 
Risk  Register. 

Updated 
assessment  and 
Risk  Register. 

Updated 
assessment  and 
Risk  Register. 

Updated 
assessment  and 
Risk  Register. 
Shipbuilder  risk 
assessments. 

Updated 
assessment  and 
Risk  Register. 
Shipbuilder  risk 
assessments. 

Updated 
assessment  and 
Production  Risk 
Register. 
Shipbuilder  risk 
assessments. 

Life  Cycle  Risk 
Register. 

rogram  health 
for 

requirements, 

budget, 

program 

manning, 

planning/ 

execution,  and 

external 

influences. 

PoPS  evaluation 
to  support  Gate 
reviews. 

PoPS  evaluation 
to  support  Gate 
reviews. 

PoPS  evaluation 
to  support  Gate 
reviews. 

PoPS  evaluation 
to  support  Gate 
reviews. 

PoPS  evaluation 
to  support  Gate 
reviews. 

PoPS  evaluation 
to  support  Gate 
reviews. 

PoPS  evaluation 
to  support  Gate 
reviews. 

PoPS  evaluation 
to  support  Gate 
reviews. 
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Table  Q-4.  SETR  Products 


ITR 

ASR 

SRR 

SFR 

PDR 

CDR 

SVR/FCA J 
PRR 

In-Service 

Reviews 

Briefing  Announcement 
Memo  issued  by  SETR 
Chairman  with  Agenda. 

Email 

invitation. 

X 

X 

X 

X 

X 

X 

X 

Briefing  by  the  SDM  with 
Program  Office  inputs 
covering  the  entrance/exit 
criteria  topics  above. 

X 

X 

X 

X 

X 

X 

X 

X 

Memo  Summarizing  SETR 
results  including 
resolution  of  resulting 
action  items  issued  by 

SETR  Chairman. 

X 

X 

X 

X 

X 

X 

X 

X 

SETR  Report  signed  by 
Program  Manager,  PEO 
Ships,  SEA  05D,  and  SEA 

05. 

Memo  is 
sufficient. 

X 

X 

X 

X 

X 

X 

X 

The  SETR  Report  shall  be  prepared,  signed,  and  distributed  30  days  of  event.  If  this  report  does  not  report  closure  of  the  event,  a  subsequent 
memorandum  shall  document  closure.  The  report  describes  the  outcomes  of  the  SETR  meeting,  including  the  following: 

a.  List  of  attendees,  including  name,  functional  area  represented,  phone  number,  and  e-mail  address 

b.  Meeting  minutes,  including  entry  criteria  status,  closure  criteria  status,  and  SETR  results 

c.  Recommendations  pertinent  to  the  technical  health  of  the  program  and  its  readiness  to  enter  the  next  phase  of  development 

d.  List  of  all  action  items,  assignees,  and  due  dates 

e.  Identification  of  all  system  specification  changes/modifications  and  all  new  performance  and  mission  implications,  as  needed. 
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APPENDIX  R 

SHIP  DESIGN  STUDY  COST  ESTIMATING  DATA  FORM 

The  Ship  Design  Study  Cost  Estimating  Data  Form  or  “cost  form”  documents  information  provided  to  SEA  05C 
for  the  purpose  of  producing  a  cost  estimate  for  a  concept  design.  The  cost  form  is  sent  to  SEA  05C  as  an 
enclosure  to  a  serialized  transmittal  memo. 

Because  no  two  ship  concept  design  studies  are  alike,  the  cost  form  is  not  actually  a  “form.”  Instead,  it  is  a 
checklist  that  indicates  typical  early-stage  design  information  that  impacts  cost.  The  information  required  for  a 
given  project  depends  on  the  ship  characteristics,  lead  time,  and  other  factors.  For  some  concept  designs,  not  all 
of  the  data  in  the  checklist  is  used.  For  others,  there  is  additional  cost-impacting  design  information  that  does  not 
appear  in  the  standard  checklist. 

In  the  early  stages  of  the  design  project,  the  naval  architect  and  the  SEA  05C  cost  engineer  discuss  data 
requirements  so  that  when  it  is  time  to  submit  the  cost  form,  the  required  data  elements  have  been  defined  and 
cost  estimation  work  can  proceed  without  delay. 

Cost  F orm  Information  Checklist 

1 .  Name  of  ship  design  study. 

2.  Requested  due  date  for  SEA  05C  to  supply  the  cost  estimate. 

3.  Description  and  discussion  of  the  design. 

•  General  background  and  mission,  including  requirements  risk. 

•  Highlights  of  specific  design  features,  particularly  the  new  and  innovative  aspects. 

•  Characterization  of  the  design  as  (a)  new,  clean-sheet  concept,  (b)  a  modified  repeat,  (c)  a  conversion, 
or  (d)  something  else. 

•  Discussion  of  modularity  and  commonality  features  at  the  ship  level.  It  may  be  useful  to  characterize 
this  in  terms  of  a  ratio  from  a  baseline  or  some  other  index.  However  as  there  is  no  standard  approach, 
it  is  left  to  the  naval  architect  and  cost  engineer  to  develop  the  best  way  for  a  given  project.  Modularity 
and  commonality  are  broken  down  by  1 -digit  SWBS  in  section  6  below. 

•  Acquisition  strategy  information.  This  includes  specification  of  the  number  ships  to  be  built  and  a 
first-cut  build  plan  showing  the  fiscal  year  of  award  and  delivery  of  lead  and  follow  ships.  Non¬ 
standard  acquisition  approaches  should  be  described  -  these  could  involve,  for  example,  the  spreading 
of  Detail  Design  work  between  contractors,  split  production  between  different  contractors, 
disintegration  of  hull  construction  from  final  outfitting,  etc. 

•  Discussion  of  technical  and  program  risk  factors.  TRLs  by  technology  element  are  provided  in  section 
8  below. 

•  Discussion  of  foreign  technologies  or  participation. 

•  Discussion  of  other  relevant  aspects  of  the  design. 
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4.  General  characteristics 

•  Hull  form  type  (Monohull,  multihull,  air  cushion  vehicle,  Small-Waterplane  Area  Twin-Hull 
(SWATH),  etc.) 

•  Length,  waterline,  and  overall 

•  Beam,  max  waterline 

•  Breadth,  extreme 

•  Depth,  amidships 

•  Draft,  to  keel,  amidships 

•  Draft,  navigational 

•  Volume,  total  enclosed  and  machinery  spaces 

•  Military/Commercial  specs 

•  Other 

5.  Weights,  1 -digit  SWBS  level 

•  Specification  of  the  baseline  ship  for  cost  estimation,  with  a  discussion  of  complexity  by  1  -digit 
SWBS,  to  enable  cost  estimating  relationships  (CERs)  to  be  modified  from  those  of  the  baseline. 

•  1 -digit  weights.  Column  3  may  be  better  presented  separately  due  to  length. 


(1) 

(2) 

(3) 

Design-related 

SWBS 

Weight 

Cost  Considerations* 

1 .  Structure 

2.  Propulsion 

3.  Electric  plant 

4.  Command  and  control 

5.  Auxiliary  machinery 

6.  Outfit  and  furnishings 

7.  Armament 
Sum  of  1  through  7 

Design  and  construction  margins 
Light  ship  weight 
Future  growth  margin 
Loads 

Full  load  displacement 


*  These  include  complexity,  modularity  and  commonality. 
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6.  Key  features 

(1)  Structure 

-  Materials  breakdown  by  weight  (mild  steel,  HY-80,  aluminum,  etc.) 

-  Ice  strengthening  (Y/N) 

-  Other. 

(2)  Propulsion  machinery 

-  Type  of  engine  configuration  (GT,  CODAG,  etc.) 

-  Number  and  model  of  main  engines. 

-  Transmission  (mechanical,  electrical). 

-  Number  and  characteristics  (diameter,  rpm,  etc.  as  needed)  of  propellers. 

-  Other. 

(3)  Electric  plant 

-  Ship  service  generator  number  and  model. 

-  Emergency  generator  number  and  model. 

-  Other. 

(4)  Command  and  control 

-  Include  specifics  in  the  GFE  equipment  list  (below) 

-  Non-standard  features  (flag  facilities,  etc.) 

(5)  Auxiliary  machinery 

-  Include  specifics  in  the  GFE  equipment  list  (below) 

-  Non-standard  features  (thrusters,  elevators,  etc.) 

(6)  Outfit  and  furnishings 


Accommodations 


Ship-Navy 

Officers 

CPO 

Other  enlisted 

Ship-MSC 

Officers 

Unlicensed  - 

Troops 

Officers 

CPO 

Other  enlisted 

Air  Wing 

Officers 

CPO 

Other  enlisted 

Flag 

Officers 

CPO 

Other  enlisted 

Total 


Habitability  Standards 
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(7)  Armament 

-  Include  specifics  in  the  GFE  equipment  list  (below) 

(8)  Load  items 

-  Non-standard  items  that  could  affect  cost. 

(9)  Protection  (Note  :  this  information  is  usually  classified) 

Shock  (Y/N) 

-  Blast  overpressure 

-  Torpedo  side  protection  system  (Y/N) 

-  Cruise  missile  protection  system 
7.  Additional  information,  as  needed 

•  Sketch  of  the  ship. 

•  3-digit  SWBS  weight  report. 

•  List  of  major  GFE. 

•  List  of  developmental  items  with  estimates  of  TRL. 

•  List  of  3 -digit  weight  changes  from  the  baseline  ship.  For  conversion  and  major  modernizations,  list  the 
major  equipment  removals. 

•  Design  for  production  features. 

•  Unusual  manning  strategies  (such  as  Blue  and  Gold  Crews,  etc.) 

•  Operations  and  Support  data  (such  as  projected  fuel  consumption,  operating  cycles/hours, 
overhaul/modernization  strategy,  etc.) 

•  Any  special  considerations  for  calculating  Disposal  Costs. 

•  Life  cycle  costs  reduction  features. 

•  Any  other  relevant  and  helpful  information. 
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APPENDIX  S 

TYPICAL  CERTIFICATIONS 

Note  that  this  table  contains  some  content  applicable  only  to  T-Ships  and  some  content  applicable  only  to  combatants.  See  the  notes  in  the  titles 
for  each  entry. 


Certification 

Program  Office 

Point  of  Contact 

Activities  to  Obtain 
Certification 

Certification 

Authority 

Expected 
Certification  Date 

Intelligence 

Acquisition 

Program  Manager 

CDD  review  by  Joint  Staff  J2 

Joint  Staff  J8 

During  CDD 

Approval 

Interoperability 

Program  C4I 

Lead 

CDD  review  by  Joint  Staff  J6 

Joint  Staff  J6 

During  CDD 

Approval 

FORCENet 

Program  C4I 

Lead 

CDD  review  by  OPNAV  N6 

OPNAV  N6 

During  CDD 

Approval 

Clinger-Cohen  Act  (CCA)  Compliance 

Program  C4I 

Lead 

Signature  of  Compliance 

Statement 

Department  of  the 

Navy  (DoN)  CIO 
with  review  by  DoD 

CIO 

Prior  to  Milestone  A 
and  B 

Spectrum  Certification 

Program  C4I 

Lead 

Signature  of  Spectrum 
Supportability  Plan  and 
associated  Form  1 494s 

OPNAV  N6  with 
review  by  Spectrum 
Support  Field 

Activities 

Prior  to  Milestone  A 
and  B 

DOD  Information  Assurance  Certification  and 
Accreditation  Process 

Program  C4I 

Lead 

Approval  of  Information 

Assurance  Strategy,  SSAA 

DoN  CIO 

Prior  to  Milestone  B 

Early  Operational  Assessment  (EOA) 

Test  and 

Evaluation 

Manager 

Operational  Test  & 

Evaluation  Force 
(OPTEVFOR)  conduct  of 

EOA 

Commander, 

Operational  Test 
and  Evaluation 

Force 

(COMOPTEVFOR), 

DOT&E 

Prior  to  Milestone  B 

Independent  Logistics  Assessment  (ILA) 

Logistics 

Manager 

ILA  Team  Review  of  Program 

PEO  Ships 

Prior  to  Milestone  B 

Training  Assessment 

Logistics 

Manager 

Navy  Training  System  Plan 

OPNAV  N1 

Prior  to  Gate  4 

Human  Systems  Integration 

SDM/SUPSHIP 

HSI  design  review 

SDM 

Prior  to  delivery 

W 

I 
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Certification 

Program  Office 

Point  of  Contact 

Activities  to  Obtain 
Certification 

Certification 

Authority 

Expected 
Certification  Date 

System  Safety 

ESOH  Manager 
and/or  Principal 
for  Safety 

Design  review  and  working 
group 

SDM 

Prior  to  delivery 

Environmental 

ESOH  Manager 
and/or  Principal 
for  Safety 

Design  review  and  working 
group 

SDM 

Prior  to  delivery 

Corrosion  Prevention  and  Control 

SDM/SUPSHIP 

Design  review  and  CPAT 

SDM 

Prior  to  delivery 

WSESRB  and/or  Shipboard  Weapons  Integration 

Team  (SWIT)  reviews  and  approval 

Principal  for 

Safety 

WSESRB/SWIT  Review 

Meetings 

WSESRB/SWIT 

Prior  to  Milestone  B 

System  Specification 

SDM 

TWH  Review  and  Signature 

TWH 

Prior  to  DD&C  RFP 
Release 

Builder’s  Certificate  (Coast  Guard  (CG)  Form  1261) 

(where  applicable  for  T-ships) 

SUPSHIP 

USCG  review  during  DD&C 
to  comply  with  Code  of 

Federal  Regulations  (CFR) 

USCG 

Prior  to  ship  delivery 

Panama  Canal  Commission  Letter 

SUPSHIP 

Panama  Canal  Commission 
review 

Panama  Canal 
Commission 

Prior  to  ship  delivery 

Panama  Canal  Package  (Documentation  Package 
provided  to  Ship) 

SUPSHIP 

Panama  Canal  Commission 
review 

Panama  Canal 
Commission 

Prior  to  ship  delivery 

Certificate  of  Inspection  (CG  Form  851)  (where 
applicable  for  T-ships) 

SUPSHIP 

USCG  review  during  DD&C 
to  comply  with  CFR 

USCG 

Prior  to  ship  delivery 

ABS  Classifications  (where  applicable  for  T-ships) 

SUPSHIP 

ABS  review  during  DD&C 

ABS 

Prior  to  ship  delivery 

Provisional  Load  Line  Certificate  (where  applicable 
for  T-ships) 

SUPSHIP 

ABS  or  other  review  during 

DD&C 

ABS  or  other 

Prior  to  ship  delivery 

International  Load  Line  Certificate  (where  applicable 
for  T-ships) 

SUPSHIP 

ABS  or  other  review  during 

DD&C 

ABS  or  other 

Prior  to  ship  delivery 

International  Tonnage  (1969  Convention)  (where 
applicable  for  T-ships) 

SUPSHIP 

ABS  or  other  review  during 

DD&C 

ABS  or  other 

Prior  to  ship  delivery 

Suez  Canal  Tonnage  (where  applicable  for  T-ships) 

SUPSHIP 

ABS  or  other  review  during 

DD&C 

ABS  or  other 

Prior  to  ship  delivery 
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Certification 

Program  Office 

Point  of  Contact 

Activities  to  Obtain 
Certification 

Certification 

Authority 

Expected 
Certification  Date 

Panama  Canal  Tonnage  (where  applicable  for  T- 
ships) 

SUPSHIP 

ABS  or  other  review  during 

DD&C 

ABS  or  other 

Prior  to  ship  delivery 

Cargo  Gear  Register  (where  applicable  for  T-ships) 

SUPSHIP 

ABS  review  during  DD&C 

ABS 

Prior  to  ship  delivery 

Acceptance  in  the  Alternate  Compliance  Program 
(ACP)  (Construction)  (where  applicable  for  T-ships) 

SUPSHIP 

ABS/USCG  review  during 

DD&C 

ABS/USCG 

Prior  to  ship  delivery 

Acceptance  in  the  Alternate  Compliance  Program 
(ACP)  (Operation)  (where  applicable  for  T-ships) 

SUPSHIP 

ABS/USCG  review  during 

DD&C 

ABS/USCG 

Prior  to  ship  delivery 

USCG  Code  of  Federal  Regulation  (CFR)  Title  33 
(Statement  of  Fact)  (where  applicable  for  T-ships) 

SUPSHIP 

ABS  review  during  DD&C 

ABS 

Prior  to  ship  delivery 

CFR  Title  46  (Statement  of  Fact)  (where  applicable 
for  T-ships) 

SUPSHIP 

ABS  review  during  DD&C 

ABS 

Prior  to  ship  delivery 

49  CFR  Title  176  (Statement  of  Fact)  (where 
applicable  for  T-ships) 

SUPSHIP 

ABS  review  during  DD&C 

ABS 

Prior  to  ship  delivery 

Safety  Construction  (Statement  of  Voluntary 

Compliance  (SOVC))  (where  applicable  for  T-ships) 

SUPSHIP 

ABS  review  during  DD&C 

ABS 

Prior  to  ship  delivery 

Safety  Equipment  (SOVC)  (where  applicable  for  T- 
ships) 

SUPSHIP 

ABS  review  during  DD&C 

ABS 

Prior  to  ship  delivery 

Safety  Radio  (GMDSS/SLR/SLT)  (SOVC)  (where 
applicable  for  T-ships) 

SUPSHIP 

ABS  review  during  DD&C 

ABS 

Prior  to  ship  delivery 

Various  Equipment  Type  Approvals  (where 
applicable  for  T-ships) 

SUPSHIP 

ABS  review  during  DD&C 

ABS 

Prior  to  ship  delivery 

MARPOL  ‘73/’78  -Air  Emissions  -  Oxides  of  Nitrogen 
(NOx)  compliance  with  Annex  VI  of  MARPOL  73/78. 
Exhaust  smoke  in  accordance  ISO  Standard  8173 

Part  III 

SUPSHIP 

Vendor  action  during  DD&C 

Shipbuilder  vendor 

Prior  to  ship  delivery 

MARPOL  ‘73/78  -  (SOVC) 

SUPSHIP 

ABS  or  other  review  during 

DD&C 

ABS  or  other 

Prior  to  ship  delivery 

MARPOL  Annex  1  (Oil)  IOPP,  COW,  etc.  (SOVC) 

SUPSHIP 

ABS  or  other  review  during 

DD&C 

ABS  or  other 

Prior  to  ship  delivery 

(/) 
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Certification 

Program  Office 

Point  of  Contact 

Activities  to  Obtain 
Certification 

Certification 

Authority 

Expected 
Certification  Date 

MARPOL  Annex  IV  (Sewage)  SOVC 

SUPSHIP 

ABS  or  other  review  during 

DD&C 

ABS  or  other 

Prior  to  ship  delivery 

Marine  Sanitation  Device  (MSD)  (MARPOL  73/78 

Annex  IV  Equivalent) 

SUPSHIP 

ABS  or  other  review  during 

DD&C 

ABS  or  other 

Prior  to  ship  delivery 

MARPOL  Annex  V  (Garbage)  SOVC 

SUPSHIP 

ABS  or  other  review  during 

DD&C 

ABS  or  other 

Prior  to  ship  delivery 

72  COLREGS  (Statement  of  Fact) 

SUPSHIP 

ABS  or  other  review  during 

DD&C 

ABS  or  other 

Prior  to  ship  delivery 

Certificate  of  Sanitary  Construction 

SUPSHIP 

United  States  Public  Health 

Service  (USPHS)/  Food  and 

Drug  Administration  (FDA) 
review  during  DD&C 

USPHS  Surgeon 

General 

Prior  to  ship  delivery 

Deratting  Exemption  Certificate 

SUPSHIP 

USPHS/FDA  review  during 

DD&C 

USPHS  Vessel 

Sanitation  Inspector 

Prior  to  ship  delivery 

Potable  water  quality  compliance  with  United  States 

Public  Health  Service  (USPHS)  requirements  (Lab 

Report) 

SUPSHIP 

Shipbuilder  Vendor  review 
during  DD&C 

Approved  laboratory 

Prior  to  ship  delivery 

Air  Purity  for  Emergency  Air  Breathing  Stations 

SUPSHIP 

Conduct  laboratory  testing 

Laboratory  certified 
by  the  State  or  the 

EPA  for  testing  air 
purity 

No  later  than  30 
days  prior  to 

Builder’s  Trials 

Personnel  Elevator  Certificate  (ASME  A17.1) 

SUPSHIP 

ASME  elevator  inspector 
review  during  DD&C 

ASME 

Prior  to  ship  delivery 

Stability  Letter 

SUPSHIP 

ABS  or  other  review  during 

DD&C 

ABS  or  other 

Prior  to  ship  delivery 

Certificate  of  Deadweight 

SUPSHIP 

ABS  or  other  review  during 

DD&C 

ABS  or  other 

Prior  to  ship  delivery 

Radio  Station  License  (where  applicable  for  T-ships) 

SDM/SUPSHIP 

ABS  or  other  review  during 

DD&C 

ABS  or  other 

Prior  to  ship  delivery 

ISM  Safety  Management  Certificate  (where 
applicable  for  T-ships) 

SDM/SUPSHIP 

ABS  or  other  review  during 

DD&C 

ABS  or  other 

Prior  to  ship  delivery 
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Certification 

Program  Office 

Point  of  Contact 

Activities  to  Obtain 
Certification 

Certification 

Authority 

Expected 
Certification  Date 

International  Ship  Security  Certificate  (SOVC) 

(where  applicable  for  T-ships) 

SDM/SUPSHIP 

USCG  review  during  DD&C 

USCG 

Prior  to  ship  delivery 

Shipborne  Automatic  Identification  System  (AIS) 

SDM/SUPSHIP 

Shipbuilder  Vendor  review 
during  DD&C 

USCG/Federal 
Communications 
Commission  (FCC) 

Prior  to  ship  delivery 

Underwater  Inspection  in  Lieu  of  Dry  Docking 
(UWILD)  (Statement  of  Fact) 

SDM/SUPSHIP 

ABS  or  other  review  during 

DD&C 

ABS  or  other 

Prior  to  ship  delivery 

ABS  statement  of  SOLAS  compliance  (where 
applicable  for  T-ships) 

SDM/SUPSHIP 

ABS  review  during  DD&C 

ABS 

Prior  to  ship  delivery 

Tactical  Air  Navigation  (TACAN)  System 

SDM/SUPSHIP 

At  sea  using  flight  inspection 
aircraft  of  Shipboard 

Electronic  System  Evaluation 
Facility  (SESEF) 

Federal  Aviation 
Administration  (FAA) 
(Regional),  SESEF 

At  sea  after  initial 
installation 

Aviation  Interface/Facilities 

SDM/SUPSHIP 

Inspection 

Naval  Air  Warfare 

Center  Aircraft 

Division  (NAWCAD) 

Lake  hurst 

After  initial 
installation 

Shipboard  Wind  Measuring  System  and  other 

Landing  and  Approach  Aids 

SDM/SUPSHIP 

Dockside  testing 

NAWCAD, 

Lakehurst 

After  initial 
installation 

Identification  Friend  or  Foe  (IFF) 

SDM/SUPSHIP 

Dockside  testing 

NAVAIR 

After  initial 
installation 

Navigation  Lights 

SDM/SUPSHIP 

Provide  verification  report  no 
later  than  6  months  prior  to 
first  sea  trials 

Judge  Advocate 

General 

Prior  to  first  sea 
trials 

AN/WSN-5  Inertial  Navigation  Set  or  AN/WSN-7  Ring 

Laser  Gyro 

SDM/SUPSHIP 

Dockside  and  at  sea 
certification  testing 

SPAWARSYSCEN 

Charleston 

After  initial 
installation 

Weapons  Systems  Pointing  and  Firing  Cutout  Zones 

SDM/SUPSHIP 

Inspection 

NSWC  CC 

Prior  to  weapons 
testing 

Degaussing 

SDM/SUPSHIP 

Inspection  and  testing 

NAVSEA  Code 

Prior  to  delivery 

C4I  Interoperability 

Program  C4I 
Lead/SUPSHIP 

Inspection  and  Testing  by  the 

Joint  Interoperability  Test 
Command  (JITC) 

Director,  Defense 
Information  Systems 
Agency 

Post  delivery 

(/) 
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Certification 

Program  Office 

Point  of  Contact 

Activities  to  Obtain 
Certification 

Certification 

Authority 

Expected 
Certification  Date 

Radio  Frequency  Radiation  (RFR)  Hazards 
(RADHAZ)  Abatement 

SDM/SUPSHIP 

Dockside  visual  inspection 
and  at  sea  instrumented 
testing 

NAVSEA  Code 

Prior  to  Post 

Shakedown 

Availability 
completion  for  lead 
ship  and  prior  to 
Acceptance  Trials 
for  follow  ships 

Electromagnetic  Compatibility 

SDM/SUPSHIP 

Dockside  visual  inspection 
and  at  sea  instrumented 
testing 

NAVSEA  Code 

Prior  to  Post 

Shakedown 

Availability 
completion  for  lead 
ship  and  prior  to 
Acceptance  Trials 
for  follow  ships 

Secure  Electrical  Information  Processing  System  - 
TEMPEST 

SDM/SUPSHIP 

Dockside  visual  inspection 
and  at  sea  instrumented 
testing 

SPAWAR 

One  month  prior  to 
delivery 

Information  Systems  Certification  and  Accreditation 

SDM/SUPSHIP 

Inspection 

SPAWAR 

One  month  prior  to 
delivery 

Readiness  for  Trials 

Program 

Manager/ 

SUPSHIP 

Shipbuilder  demonstrates 
readiness  for  sea  trials 

Program  Manager 

Prior  to  beginning 
trials 

Combat  System  Qualification  Testing 

SDM 

Various  Field  Activities  and 

Ranges 

Various  Field 

Activities  and 

Ranges 

Post  Delivery 

Operational  Evaluation  (OPEVAL) 

Test  and 

Evaluation 

Manager 

Conduct  of  OPEVAL 

COMOPTEVFOR 

Prior  to  Initial 

Operational 

Capability 
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APPENDIX  T 
ABS  INVOLVEMENT 

For  applicable  T-ship  Programs  during  the  Detail  Design,  ABS  works  with  the  design  agent.  Shipbuilder,  and 
HM&E  system  vendors/integrators  to  ensure  that  the  ship,  and  its  HM&E  systems  and  mission  system  interfaces, 
conform  to  the  applicable  Rule  set  and  any  other  requested  certification  standards,  such  as  SOLAS  or  MARPOL. 
The  final  product  used  to  guide  DD&C  will  be  the  approved  Ship  Specification.  Using  the  Rule  set  and  Ship 
Specification,  the  agent  or  team  building  the  ship  (the  contractor)  will  produce  an  index  of  the  set  of  submittals 
(technical  drawings,  plans,  studies,  analyses,  and  other  engineering  documentation)  they  propose  as  necessary  and 
sufficient  to  demonstrate  that  their  design  and  approach  is  compliant  with  the  invoked  Rule  set  and  the  Ship 
Specification.  They  will  submit  this  to  ABS  and  the  TWHs  for  concurrence.  Once  concurrence  is  achieved,  this 
index  becomes  the  baseline  tracking  document  for  assessing  achievement  of  classification  design  approval.  It  is 
the  contractor’s  responsibility  to  review  the  Rule  set  to  identify  submittal  requirements  and  concurrence  by  ABS 
and  the  TWHs  does  not  guarantee  that  additional  submittals  won’t  be  subsequently  identified  as  necessary.  The 
goal  is  to  demonstrate  compliance  with  the  Rule  set.  In  order  to  facilitate  this  process,  a  summary  of  submittal 
requirements  has  been  developed  which  may  be  used  as  the  entry  point  by  the  contractor  for  this  process.  The 
documentation  required  as  submittals  is  comprised  of  what  is  normally  considered  to  be  Contract  and  Contract 
Guidance  level  and  is  what  is  used  to  verify  classification  compliance.  Documentation  reviewed  and  stamped 
“Approved”  or  “Approved  with  Comment”  by  ABS  is  what  is  used  ABS  Surveyors  on-site  in  the  Shipbuilder  and 
at  vendor  facilities  to  verify  compliance  with  the  classification  requirements.  In  most  cases,  the  Shipbuilder  will 
develop  or  have  developed  for  their  use  production  or  assembly  drawings.  It  is  the  Shipbuilder’s  responsibility  to 
ensure  that  these  production  level  drawings  are  fully  compliant  with  those  “approved”  drawings  upon  which  they 
are  based.  Should  it  be  found  that  variance  from  the  approved  drawings  has  occurred,  it  is  the  Shipbuilder’s 
responsibility  to  either  correct  the  error  or  demonstrate  to  ABS  and  the  TWHs  that  what  has  been  produced, 
although  different  from  what  was  “approved”,  is  still  compliant  with  the  Rule  set.  As  review  of  submittals 
proceeds,  ABS  will  provide  to  the  submitter  guidance  in  the  form  of  “Comments”.  “Technical  Comments”  relate 
areas  where  the  submittal  is  not  in  compliance  with  the  Rule  set  or  where  not  enough  information  has  been 
provided  to  demonstrate  compliance.  “Surveyor  Comments”  relate  areas  where  verification  of  compliance  can 
only  occur  at  the  Shipbuilder  or  vendor  facility  and  such  verification  is  left  to  the  attending  ABS  Surveyor.  A 
Classification  Certificate  cannot  be  delivered  to  the  Shipbuilder  until  all  such  Comments  have  been  closed 
(satisfactorily  addressed).  The  Naval  Administration  and  TWHs  will  accept  the  design  and  authorize 
construction,  based  in  part  on  the  Shipbuilder’s  receipt  of  ABS  and  other  approvals.  As  the  contractor  transitions 
to  construction  and  production  level  drawings  are  produced,  it  may  be  determined  by  the  SUPSHIP  CHENG  that 
he  would  like  to  review  some  of  these  drawings.  Should  he  find  that  these  drawings  are  not  in  compliance  with 
the  approved  submittals  or  the  governing  Rule  set,  notification  should  be  given  to  the  contractor  and  ABS. 
Corrective  action  is  the  responsibility  of  the  contractor.  Compliance  with  the  Rule  set,  building  to  the  approved 
submittals,  and  satisfaction  of  comments  is  the  responsibility  of  the  contractor. 

As  mentioned  above,  there  are  a  number  of  vendor  supplied  components  and  systems  which  must  be  certified  by 
ABS  and/or  the  TWHs  for  the  vendor  and  appropriate  certification  delivered  to  the  contractor  with  the  equipment 
to  verify  compliance.  Such  equipment  and  systems  are  identified  in  the  Rules.  It  is  the  contractor’s  responsibility 
to  provide  to  ABS  and  the  TWHs  a  consolidated  list  of  all  equipment,  systems,  and  components  being  procured 
from  vendors.  ABS  and  the  TWHs  will  identify  to  the  contractor  those  items  requiring  individual  certification  at 
the  vendor  facility  and  such  will  be  tracked  using  the  contractor  supplied  Vendor  Listing.  A  majority  of  this  is  to 
be  attended  at  the  vendor  facility  by  an  ABS  Surveyor.  Some  of  it  -  especially  software  -  must  be  certified  by  the 
TWHs  and  ABS  only  tracks  satisfaction  of  TWHs  certification  to  facilitate  ultimate  classification.  The  TWHs 
may  identify  his  desire  to  have  Government  Source  Inspection  at  some  of  these  facilities  in  addition  to  ABS 
Surveyor  attendance. 
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A  Rule  requirement  is  that  the  contractor  provide  to  ABS  and  the  TWHs  both  an  Integrated  Test  Plan  and  a 
Consolidated  Trials  Plan,  each  of  which  identifies  those  tests  and  trials  which  should  be  attended  by  ABS  and/or 
the  TWHs.  ABS  and  the  TWHs  will  review  this  and  work  with  the  contractor  to  ensure  it  is  complete  and 
appropriate  and  to  ensure  coordination  of  attendance.  Individual  test  and  trial  procedures  are  to  be  submitted  by 
the  contractor  to  the  ABS  Surveyor  and  on-site  SUPSHIP  office  for  review  in  accordance  with  the  approved  plans 
in  order  to  achieve  concurrence  that  the  tests  and  trials  are  technically  sufficient  and  appropriate. 

During  the  construction  portion,  ABS  will  carry  out  survey,  inspection  and  testing  of  the  ship,  HM&E  systems 
and  mission  system  interfaces  to  ensure  compliance  with  the  approved  submittals  and  the  Rules.  The  process  for 
carrying  this  out  is  defined  in  the  relevant  ABS  Process  Instruction  and  interface  with  SUPSHIP  is  outlined  in  the 
“Business  Rules”. 

It  is  important  to  be  aware  of  several  facts: 

1 .  The  Surveyor  uses  the  Approved  or  Approved  with  Comment  submittals  as  his  basis  for  attending  the  ship. 

His  job  is  to  ensure  that  the  vessel  is  built  in  accordance  with  these  drawings.  He  ordinarily  does  not  use 
production  construction  drawings  as  these  are  produced  far  too  late  in  the  program  to  have  been  reviewed  and 
approved  prior  to  construction.  The  Surveyor  must  interpret  through  his  experience  the  fact  that  the  as-built 
configuration  complies  with  the  approved  submittals  and,  thus,  the  Rules. 

2.  The  Surveyor  uses  his  experience  and  technical  expertise  to  ensure  that  the  fabrication  processes  are  compliant 
with  the  Rule  requirements.  Inevitably  situations  will  arise  which  require  interpretation  or  assessment  of  the 
impact  of  non-compliant  work.  The  Surveyor  often  interfaces  with  yard  personnel  to  identify  approaches  which 
may  be  acceptable  or  may  mitigate  any  adverse  impact.  He  will  consult  as  necessary  with  relevant  Technical 
support  to  ensure  he  stands  on  solid  ground.  In  these  cases,  it  is  incumbent  on  the  Surveyor  to  seek  concurrence 
from  the  relevant  TWHs. 

3.  The  Surveyor  conducts  surveys.  He  is  not  an  inspector.  He  must  use  his  expertise  and  knowledge  of  the  yard 
to  gauge  the  degree  of  attendance  necessary  for  the  various  processes  taking  place.  He  is  not  a  substitute  for  the 
Quality  Assurance  (QA)  function  of  the  yard.  It  is  expected  that  the  yard  will  have  a  functioning  and  competent 
QA  organization.  He  will  adjust  the  level  of  his  attendance  to  match  the  degree  of  competence  exhibited  by  yard 
production  personnel  and  the  level  of  quality  observed.  It  may  become  necessary  to  cease  attendance  if  the  yard 
demonstrates  the  unwillingness  or  inability  to  adequately  perform  in  this  area.  To  relieve  a  yard  of  the 
accountability  for  its  own  quality  through  assumption  of  evermore  intense  inspection  sets  up  an  unwinnable  game 
of  “catch-me-if-you-can”  and  results  inevitably  in  the  owner  assuming  the  risks  and  costs  associated  with  the  poor 
work. 

The  Surveyor  really  has  two  primary  goals  -  to  create  a  relationship  of  trust  and  credibility  with  yard  personnel  so 
that  he  can  advise  them  on  how  to  achieve  success  in  what  they  are  building  and,  at  the  same  time,  function  as  an 
agent  for  the  TWHs  to  assess  compliance.  This  is  a  tricky  challenge  but  when  it  is  successfully  carried  out,  all 
parties  benefit.  The  yard’s  technical  abilities  are  improved  and  the  owner  receives  a  compliant  ship  without  the 
investment  of  unaffordable  amounts  of  inspection.  A  yard  which  tries  to  game  this  is  the  loser  as  their  credibility 
decreases  and  their  rework  costs  increase. 

At  the  end  of  the  Build  phase,  ABS  issues  a  Class  Certificate,  along  with  other  certifications  as  requested  by  the 
Naval  Administration.  These  certificates  are  delivered  to  the  Naval  Administration  as  part  of  the  overall  package 
required  for  acceptance  into  Fleet  service. 
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The  SIM  is  responsible  for  ensuring  achievement  of  the  safety,  cost,  and  requirements  of  any  associated  weapons 
systems  under  development.  The  SDM  and  SIM  are  also  responsible  for  technical  problems  identification  and 
resolution  within  the  scope  of  their  technical  warrants.  Other  problems  are  referred  to  the  SDM  and  SIM  for 
resolution  by  the  appropriate  TWH.  The  SDM  retains  technical  authority  for  the  total  ship  and  also  normally 
advises  the  program  on  the  resolution  of  technical  issues  and  supports  the  development  of  and  approves  the 
technical  adequacy  of  engineering  changes.  The  SDM  is  responsible  for  managing  the  contractual  baseline  (e.g.. 
System  and/or  Shipbuilding  Specifications,  Contract  Drawings,  PPDs,  and  other  data  forming  the  Allocated 
Baseline).  The  Shipbuilder  performs  CM  of  the  Detail  Design  or  the  Product  Baseline.  The  SIM  is  responsible 
for  the  overall  system  integration  on  the  ship  for  applicable  weapons  systems,  and  will  assist  the  SDM  for  all 
system  integration  issues  during  construction  and  life  cycle  management  and  sustainment. 
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APPENDIX  U 

CONFIGURATION  CONTROL/MANAGEMENT 

U.1  INTRODUCTION. 

Configuration  control  is  the  process  of  establishing  a  design  baseline,  and  then  subjecting  proposed  changes  to 
this  baseline  to  management  attention  and  approval.  Configuration  control  can  be  formal  or  informal  and  in  both 
there  is  a  clearly  identified  review  and  approval  hierarchy  with  a  record  of  the  basis  for  changing  the  design. 

U.1.1  Definitions. 

U.  1 . 1 . 1  Configuration  Control.  Controlling  changes  to  the  ship  design  configuration  documents. 

U.1. 1.2  Configuration  Item  (Cl).  Items  may  differ  widely  in  complexity,  size,  and  kind.  Examples  are  a  ship, 
propulsion  system,  ship  arrangement  and  personnel  access  system,  navigation  system,  combat  system,  embedded 
computer,  computer  program,  electronic  system,  feed  pump,  test  equipment,  or  a  round  of  ammunition.  A  Cl 
satisfies  an  end-use  function  or  aggregate  of  functions.  Thus,  a  top-level  or  “parent”  item,  such  as  a  ship,  is 
composed  of  a  number  of  lower  level  items,  such  as  the  major  ship  systems,  to  which  various  functions  have  been 
allocated  by  the  designer.  Similarly,  functions  of  these  lower  level  items  are  sub  allocated  downward  throughout 
a  hierarchical  family  of  CIs.  This  top-down  hierarchy  of  CIs,  stalling  with  the  ship,  is  similar  to  the  ship  work 
breakdown  structure. 

U.1 .1 .3  Contract  Drawing.  A  NAVSEA  drawing,  or  equivalent  data,  prepared  during  the  Preliminary  Design 
and  Contract  Design  phase,  delineates  required  design  features  of  the  ship.  No  departure  from  details  of  a 
Contract  Drawing  shall  be  made  without  specific  NAVSEA  approval. 

U.1 .1 .4  Contract  Guidance  Drawing  A  NAVSEA  drawing,  or  equivalent  data,  prepared  during  Preliminary 
and  Contract  Design  phase,  identified  as  “Contract  Guidance  Drawing,”  which  illustrates  one  alternative  for 
providing  required  design  features  of  the  ship.  The  contractor  may  deviate  from  this  solution  or  develop  his  own 
so  long  as  the  resulting  design  incorporates  the  required  design  features.  A  Contract  Guidance  Drawing  does  not 
necessarily  depict,  nor  is  it  intended  that  it  depict,  all  features  and  details  of  the  systems  and  structures  to  which  it 
relates.  It  serves  the  purpose  of  providing  information  that,  when  utilized  in  conjunction  with  applicable 
specification  requirements,  Contract  Drawings,  project-peculiar  documents,  and  other  information,  may  assist  in 
Detail  Design.  Contract  Guidance  Drawings  will  not  necessarily  be  updated  or  revised  to  reflect  future 
modification  or  changes  to  the  specifications.  Contract  Guidance  Drawings  have  fallen  out  of  use  because  in 
practice  they  are  used  as  Contract  Drawings. 

U.  1 . 1 .5  Project-Peculiar  Document.  A  government  document  included  in  the  list  of  Project-Peculiar 
Documents.  No  departure  from  details  of  a  Project-Peculiar  Document  shall  be  made  without  specific  approval 
from  the  government. 

U.1. 1.6  Formal  Control.  Formal  control  is  characterized  by  before-the-fact  approval,  specific  documentation, 
and  processing  requirements.  A  formal  request  must  be  submitted  by  anyone  desiring  to  make  a  change  to  a 
formally  controlled  aspect  of  the  ship  design.  The  originator  of  the  change  request  is  responsible  for  identifying 
the  ship  and  system  level  impact  of  the  changes,  such  as  weight,  moment,  cost  and  manning. 
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U.1.1.7  Informal  Control.  Informal  control  change  procedures  are  characterized  by  delegation  of  approval 
authority  to  the  SEM  or  TL  level  and  a  minimum  of  documentation.  In  this  mode,  changes  to  the  existing  ship 
baseline  documents  are  identified  and  proposed  to  the  cognizant  TL  or  SEM.  If  the  TL/SEM  approves  the 
change,  he  will  advise  custodians  of  the  appropriate  documents  (e.g.,  the  weights  TL  for  the  weight  report).  The 
SDM  and  DIM  are  kept  advised  by  the  SEM  of  such  actions  in  a  timely  manner.  The  SEM  determines  the  degree 
of  documentation  required  to  preserve  an  audit  trail  of  design  evolution  for  traceability  and  reevaluation  of  earlier 
decisions. 

U.1.2  General.  A  configuration  control  plan  shall  be  included  in  the  Engineering  Management  Plan  or  as  a 
separate  document  referenced  in  the  Engineering  Management  Plan.  The  configuration  control  plan  shall  address 
an  informal  procedure  for  interface  control  between  the  various  products  being  developed  as  well  as  formal 
control  for  selected  products. 

Configuration  Change  Control  is  the  systematic  process  of  evaluating,  coordinating,  and  approving  or 
disapproving  change  proposals.  Once  the  baseline  is  under  formal  configuration  control,  all  requested  changes 
affecting  the  baseline  are  formally  prepared  and  well  defined  to  ensure  that  each  change’s  impact  on  the  overall 
program  is  fully  considered. 

Before  establishment  of  the  Configuration  Control  Baseline  (CCBL),  change  proposals  as  they  occur  shall  be 
identified  to  the  responsible  TL  for  review  and  evaluation.  Upon  a  determination  by  the  TL  that  the  change 
proposal  does  not  exceed  the  primary  constraints  of  the  ship’s  principal  characteristics,  the  CDD,  or  impact  other 
areas  of  the  ship’s  design,  the  TL,  if  he  concurs  with  the  change,  shall  incoiporate  it  or  recommend  it  be 
incorporated  into  the  appropriate  design  document.  If  the  TL  believes  the  change  proposal  exceeds  the  constraints 
placed  on  the  design  or  otherwise  seriously  impacts  the  design,  he  shall  provide  rationale  and  recommend 
rejection  of  the  change  proposal  via  the  SEM,  other  involved  TLs,  and  the  DIM.  The  SDM,  DIM,  SE,  and 
primary  TL  shall  review  the  rationale  for  rejection  and  recommend  its  acceptance  or  need  for  additional 
review/evaluation. 

After  formal  establishment  of  the  CCBL  in  the  Preliminary  Design  and  Contract  Design  phase,  similar  change 
proposals  affecting  the  baseline  shall  be  prepared  on  a  change  request  form  and  shall  be  formally  reviewed  and 
acted  on  by  the  ship  Design  Team. 

Long  lead  and  government  furnished  or  government  specified  material,  especially  equipment  and  systems  in  the 
combat  systems  area,  will  have  an  impact  on  what  needs  to  be  placed  under  configuration  control.  Arrangements 
for  interface  control  shall  be  discussed  in  the  Configuration  Control  Plan. 

Drawings/data  may  show  both  formally  and  informally  controlled  items  throughout  the  design.  At  the  other 
extreme,  only  a  fraction  of  the  equipment  listed  in  the  Master  Equipment  List  (MEL)  will  ever  be  subjected  to 
formal  control  for  reasons  of  weight  and  space  limitations,  delivery  time,  unique  operating  requirements,  selection 
as  GFE,  or  because  of  requirements  direction.  However  major  system  interfaces  will  be  controlled. 

Prior  to  the  time  when  significant  design  iterations  are  halted  (i.e.,  the  design  “freeze”),  formal  control  is 
exercised  on  a  selective  basis  over  changes  such  as  those  involving  customer-dictated  requirements  or  those 
having  major  impact  on  ship  characteristics;  e.g.,  hull  lines,  ship  manning,  ship  weight,  location  of  major  topside 
equipment,  speed,  and  endurance.  The  number  of  ship  system  elements  subject  to  formal  control  increases 
following  a  design  freeze. 

U.2  RESOLUTION  OF  TECHNICAL  ISSUES. 

It  may  become  necessary  from  the  viewpoint  of  a  Program  Manager  or  SDM  to  make  some  compromises  to  meet 
design  constraints.  When  such  compromises  jeopardize  the  technical  adequacy  of  the  product  or  the  integrity  of 
the  design,  each  Design  Team  member  must  understand  their  personal  responsibility  to  ensure  the  situation  is 
brought  to  the  attention  of  the  SDM  and  the  responsible  TWH.  In  such  instances,  the  concerns  must  be  made 
known  in  a  logical,  reasonable  fashion,  and  the  rationale  for  final  decisions  must  be  documented. 
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U.3  DESIGN  PHASE  CONFIGURATION  CONTROL 

U.3.1  Feasibility  Studies.  During  Feasibility  Studies,  there  is  normally  no  formal  configuration  control. 

Control  over  the  configuration  is  achieved  by  means  of  the  developing  CDD  and  formal  and  informal  discussions 
with  the  Sponsor  chaired  Requirements  IPT  established  for  the  specific  ship  program.  At  the  completion  of 
Feasibility  Studies,  the  CDD  becomes  the  configuration  control  baseline  for  the  start  of  the  Preliminary  and 
Contract  Design  phase. 

U.3. 2  Preliminary  and  Contract  Design  Phase.  During  the  Preliminary  Design  and  early  Contract  Design 
phases,  only  the  CDD,  Ship  Specification  (depending  on  the  acquisition  strategy),  and  later  the  ship’s  lines  are 
normally  controlled.  It  is  not  until  the  middle  of  Contract  Design  that  the  list  of  controlled  documents  typically 
grows  to  include  general  arrangements,  topside  design.  Ship  Specification,  master  equipment  list  and  other 
contract  documents.  The  CDD  and  the  acquisition  decision  memoranda  (ADM)  are  the  primary  baseline  control 
documents  throughout  this  design  phase. 

Configuration  control  during  the  last  half  of  the  Preliminary  Design  and  Contract  Design  phase  shall  consist  of: 

•  Identification  of  configuration  control  items. 

•  Performing  change  control. 

•  Providing  status  reports  on  each  proposed  change. 

•  Performing  design  reviews. 

When  deliverables  have  been  identified,  the  configuration  items  to  be  controlled  shall  be  defined  in  the 
Configuration  Control  Baseline.  Normally,  the  lines  will  have  been  frozen  earlier.  Other  drawings/data  and  the 
Ship  Specifications  will  be  frozen  at  various  stages  of  the  Contract  Design  phase.  The  design  freeze  date  for  each 
item  will  be  determined  by  the  interface  requirements  necessary  to  have  an  integrated  design  package  for  review 
and  approval  prior  to  release  of  the  RFP  for  Preliminary  Design,  Contract  Design,  LLTM,  or  DD&C.  For 
example,  key  portions  of  the  ship  general  arrangements  drawings/data  must  be  frozen  early  in  order  to  permit 
other  drawings,  data,  and  calculations  to  reflect  the  correct  ship  arrangements.  As  each  document  is  frozen,  it  will 
be  added  to  the  CCBL.  After  being  added  to  the  CCBL,  all  future  changes  to  that  item  will  be  formally  controlled 
as  described  later. 

Judgment  must  be  used  in  deciding  when  to  impose  configuration  control.  If  it  is  imposed  too  soon,  the  design 
process  will  be  slowed  unnecessarily.  On  the  other  hand,  sufficient  time  must  be  allowed  to  ensure  that 
specifications  and  drawings  are  consistent  at  Navy  circulation. 

U.4  RESPONSIBILITIES. 

U.4.1  Ship  Design  Manager.  The  Ship  Design  Manager  shall: 

•  Approve  the  configuration  management  program  to  be  developed,  implemented,  and  operated. 

•  With  Program  Office  participation,  establish  and  convene,  when  necessary,  a  NAVSEA  Adjudication 
Board  (NAB  ). 

•  Approve,  disapprove,  or  defer  all  baseline-impacting  changes  after  the  NAB  establishment. 

•  Review  and  approve  all  matters  affecting  program  resources,  contract  costs,  and  schedules. 
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U.4.2  Design  Integration  Manager.  DIM  shall  be  responsible  for  the  operation  of  CM  within  the  Preliminary 
Design  and  Contract  Design  project.  Specifically,  the  DIM  shall  be  responsible  for: 

•  Developing  and  updating  the  Preliminary  Design  and  Contract  Design  phase  CM  procedures  and 
directives. 

•  Evaluating  the  ship  and  intersystem  impact  of  proposed  changes,  including  the  ship  and  design  costs  as 
well  as  alternatives. 

•  Appraising  the  SDM  of  work  priorities  and  status  of  all  CM  related  matters. 

Note:  If  there  is  no  DIM  assigned  to  the  project,  the  SDM  shall  perform  the  tasks  listed  as  being  the 
responsibility  of  the  DIM. 

U.4.3  Systems  Engineering  Managers.  Systems  Engineering  Managers  are  responsible  for: 

•  Initiating,  with  the  responsible  life  cycle  manager,  an  appeal  of  any  technical  decision. 

•  Sponsoring  all  change  request  forms  originating  in  their  functional  area  of  responsibility. 

•  Approving,  disapproving,  or  deferring  all  baseline-impacting  changes  after  the  NAB  establishment. 

•  Reviewing  and  approving  all  matters  affecting  program  resources,  contract  costs,  and  schedules. 

U.4.4  Task  Leaders.  Task  Leaders  are  responsible  for: 

•  Identifying  any  conflict,  deficiency,  or  new  requirement  and  initiating  change  requests  in  their  areas  of 
responsibility. 

•  Initiating  change  requests,  when  needed,  to  interfacing  systems. 

•  Initiating  an  appeal  of  any  technical  decision. 

•  Reviewing  all  change  requests  affecting  responsible  areas  and  interface  areas. 

•  Implementing  approved  changes  within  their  cognizant  technical  areas. 

U.4.5  Specification  Manager.  The  Specification  Manager  is  responsible  for: 

•  Establishing  a  specification  development  schedule. 

•  Developing  a  specification  configuration  management  plan. 

•  Providing  specification  writing  training  and  guidance. 

•  Establishing  procedures  for  the  flow  of  change  request  forms. 

•  Establishing  and  implementing  change  request  form  control  system. 

•  Distribution  of  change  request  forms  to  responsible  codes. 

•  Maintaining  a  status  record  for  each  change  request  form. 

•  Ensuring  Ship  Specifications  comply  with  the  NTSP  (drawings  and  ship  specifications  appendix) 
requirement. 

•  Assisting  SDMs  getting  Ship  Specifications  certified. 

U.4.6  Program  Office.  The  Program  Office  will  participate  in  the  ongoing  reviews  of  the  Contract  Design 
package  to  assure  that  the  contract  package,  when  made  available  to  the  Shipbuilder,  is  adequate  for  contractual 
purposes  and  describes  a  ship  that  meets  the  operational  requirements  established  by  OPNAV.  A  primary 
objective  of  the  Review  is  to  expose  the  Contract  Design  to  OPNAV,  the  Fleet,  INSURV,  and  other  Material 
Commands  for  review.  This  exposure  is  intended  to  solicit  comments  on  the  design  prior  to  signature  and 
subsequent  contractual  actions  for  building  the  ship.  Designated  SUPSHIPS  will  be  invited  to  participate. 
Design  briefings  for  INSURV,  SUPSHIPS,  and  the  Fleet  should  be  made  prior  to  circulation  of  the  package. 
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U.4.7  Prospective  Shipbuilders.  Prospective  Shipbuilders  will  participate  in  the  Navy  Review  to  perform  an 
in-depth  review  of  the  design  package.  They  will  examine  the  Ship  Specifications,  Contract  Drawings,  and 
Project-Peculiar  Documents  and  DRL  as  an  integrated  ship  design  to  establish  adequacy,  sufficiency,  and 
producibility  of  the  total  design.  The  goal  of  this  in-depth  total  design  review  is  to  develop  comments, 
which,  when  implemented,  would  result  in  a  data  package  that  the  Shipbuilder  would  be  willing  to  accept  as  the 
basis  for  a  Detail  Design  and  ship  production  contract. 

U.5  NAVSEA  ADJUDICATION  BOARD. 

Once  the  design  is  under  configuration  control,  no  changes  are  made  to  the  Ship  Specifications,  drawings,  and 
project-peculiar  documents  without  processing  through  a  design  evaluation  system.  Within  NAVSEA  this  system 
has  been  referred  to  for  some  ship  programs  as  the  NAB  system.  The  NAB  system  allows  every  engineer  the 
opportunity  to  submit  change  request  forms  to  correct  design  deficiencies.  These  change  requests,  submitted  on 
NAB  Evaluation  Sheets,  are  commonly  referred  to  as  “NABs”  and  are  forwarded  to  the  cognizant  TL.  The  NAB 
must  be  answered  by  the  responsible  TL.  The  final  action  on  each  approved  or  modified  change  request  form 
must  include  the  actual  wording  that  will  go  into  the  specification  or  the  exact  changes  that  will  be  made  to  the 
drawings  or  project-peculiar  documents.  The  affected  TL  routes  the  comment  to  the  SEM  for  approval  or 
concurrence  prior  to  passing  it  to  higher  authority.  The  SDM  or  NAB  must  approve  major  and  critical  comments 
and  any  comments  not  resolved  at  lower  levels.  Often  Shipbuilders  are  also  tasked  to  comment  on  the  package. 

In  addition,  other  Navy  activities  and  the  Fleet  may  submit  comments.  There  will  typically  be  3,000  to  5,000 
proposed  changes  during  circulation. 

The  NAB  is  not  an  exercise  in  shuffling  paper  although  it  may  seem  that  way  at  times.  Communication  between 
dozens  of  TLs  on  thousands  of  comments  is  difficult  at  best  and  all  but  useless  if  changes  and  responses  are  not 
properly  identified. 

Proposed  changes  to  the  specifications  are  submitted  by  attaching  copies  of  only  the  applicable  specification 
pages  to  a  completed  NAB  Evaluation  Sheet  and  by  marking  the  changes  on  the  respective  pages.  Proposed 
changes  to  drawings  are  submitted  by  attaching  a  copy  of  only  that  portion  of  the  drawing  affected,  marked  up 
with  the  change.  If  possible,  this  markup  should  be  the  same  size  as  the  NAB  Evaluation  Sheet  to  facilitate 
reproduction  efforts.  Equivalent  electronic  workflow  systems  may  be  employed  to  speed  the  process. 

The  Ship  Design  Manager  or  the  Deputy  Ship  Design  Manager  will  chair  the  NAB.  The  Program  Office 
shall  participate  -  sometimes  as  a  co-chair.  The  Specifications  Manager  and  his  staff  provide  administrative 
support.  The  SEM  for  each  functional  area  will  also  be  a  member  of  the  NAB.  Shipbuilders  and 
Supervisors  of  Shipbuilding  representatives  may  also  be  represented. 
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NAB  Evaluation  Sheets  will  be  processed  as  follows.  Equivalent  electronic  workflow  systems  may  be  employed. 

•  Originators  send  evaluation  sheets  to  the  responsible  SEM  who  copies  to  the  Specifications  Manager  or 
Specifications  Manager  who  then  forwards  to  the  responsible  SEM.  Evaluation  sheets  are  logged  in 
by  the  Specifications  Manager. 

•  Cognizant  SEM  reviews  with  the  responsible  TL  and  recommends  approval,  denial, 
modification  or  consideration  by  the  NAB. 

•  Specifications  Manger  distributes  evaluation  sheets  with  SEM  recommendation  to  the 
originator,  other  stakeholders,  the  DIM,  and  SDM. 

•  Other  stakeholders  may  return  evaluation  sheets  to  the  Specifications  Manager  with  comments. 

•  Based  on  the  comments,  the  proposed  change  may  be  approved,  denied,  or  modified  by  the  DIM 
and  SDM  or  brought  to  the  NAB.  Approved,  denied,  and/or  modified  changes  will  be  returned 
to  the  originator  and  stakeholders  by  the  Specifications  Manager. 

•  NAB  adjudicates  evaluation  sheets. 

•  The  DIM  and  SDM  sign  the  NAB  and  all  other  adjudicated  evaluation  sheets. 

•  The  Specifications  Manager  maintains  a  file  reflecting  latest  status  of  all  evaluation  sheets. 

The  procedures  for  processing  Evaluation  Sheets  comments  provides  for  all  sheets  to  be  sent  to  the  cognizant 
SEM  who  will  adjudicate  (approve,  approve  with  modification,  or  reject)  the  comment  except  for  those  items 
which  he  determines  are  of  sufficient  importance  to  be  referred  to  the  NAB.  The  decision  by  the  SEM  whether  to 
adjudicate  or  refer  to  the  NAB  is  critical  to  the  whole  adjudication  process.  It  is  intended  that  most  evaluation 
sheets  will  be  adjudicated  by  the  SEM/TL,  however,  key  adjudication  decisions  should  be  made  by  the  NAB. 
Typical  of  Evaluation  Sheets  comments,  which  normally  refer  to  the  NAB,  are: 

•  Comment  appears  desirable  to  the  SEM/TL  but  implementation  would  result  in  deviation  from  Project 
and  Command  requirements  e.g.,  NAVSEA  policy,  standards,  and  requirements. 

•  Comment  appears  desirable  to  the  SEM/TL  but  implementation  would  result  in  change  in  significant  ship 
characteristics  such  as  weight,  speed,  and  endurance. 

•  Comment  appears  undesirable  to  the  SEM/TL  but  decision  may  be  of  interest  to  higher-level 
commands  such  as  Program  Office,  SDM,  etc. 

•  Implementation  of  comment  appears  desirable  but  has  multiple  interface  ramifications. 

•  Approval  of  comment  recommended  by  SEM  but  implementation  of  the  comment  would  result  in  not 
meeting  ship  design  schedules. 

•  Comment  appears  to  have  merit,  but  SEM  would  like  NAB  input  into  the  adjudication. 

Following  the  adjudication  period,  the  NAB  shall  conduct  NAB  reading  sessions  of  the  specifications  and 
drawings  in  order  to  assure  that  they  are  consistent,  satisfy  all  imposed  design  constraints,  and  are  technically 
adequate  for  use  in  ship  procurement.  The  session  will  involve  all  NAB  members.  As  each  section  and 
associated  drawings  are  reviewed,  the  responsible  SEM  shall  inform  the  NAB  of  any  significant  changes  made 
since  circulation  for  review.  Comments  or  changes  developed  during  the  NAB  Reading  Session  will  be 
adjudicated. 

It  should  be  noted  that  each  Ship  Design  Manager  uses  a  NAB  type  of  CM  process  during  technical  package 
development;  however,  it  may  be  called  a  Design  Decision  Memorandum  or  Specification  Change  Proposal. 

The  particular  details  for  specification  configuration  management  shall  be  documented  in  each  program’s 
Specification  Management  Plan. 
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U.6  CHANGE  CONTROL  DURING  DETAIL  DESIGN  AND  CONSTRUCTION. 

As  technical  life  cycle  managers  for  ships,  through  the  ship  life  cycle,  SEA  05  must  be  involved  in  configuration 
control  during  DD&C. 

The  assigned  SDM  shall  participate  in  all  ship-level  Configuration  Control  Boards  (CCBs).  ECPs  shall  be 
forwarded  to  the  TWHs  and  have  progress  tracked  by  the  SDM.  TWHs/SEMs  shall  prepare/review  ECPs  in  a 
timely  fashion  to  avoid  delaying  CCB  actions. 

The  SDM  shall  have  full  agreement  within  SEA  05  before  his  position  is  presented  to  the  CCB.  Any 
disagreement  between  the  SDM  and  TWH/SEMs  will  require  prior  adjudication  through  the  chain  of  command  up 
to  SEA  05  if  necessary. 

The  ECP  status  report  should  be  used  by  the  SDM  and  TWHs/SEMs  to  track  action  on  a  configuration  change. 
The  SDM  shall  ensure  that  the  TWHs/SEMs  receive  the  necessary  feedback. 

TWHs/SEMs/SDM  shall  initiate  an  official  reclama  through  the  Technical  Authority  if  they  do  not  agree  with  a 
final  action  taken  by  CCB/Program  Office.  The  issue  shall  not  be  dropped  just  because  the  CCB  or  Program 
Manager  decided  contrary  to  Technical  Authorities  position.  While  the  final  decisions  rests  with  the  Program 
Office  (the  Shipbuilder  can  also  reject  an  HMR  because  of  cost  or  schedule  reasons),  SEA  05  is  obligated  to 
assure  the  technical  adequacy  of  each  ship  design.  SEA  05  must  vigorously  pursue  its  position  on  significant 
issues  and  the  codes  must  keep  their  management  informed.  The  SDM/TAEs  shall  elevate  specific  problems  to 
SEA  05  on  a  case  basis  as  required. 

The  SDM  will  have  access  to  all  Field  Modification  Requests  (FMRs),  Deviations,  and  Waivers  and  conduct 
review  for  technical  adequacy.  The  SDM  shall  identify  to  the  Program  Office  all  changes  considered 
technically  unacceptable.  The  SDM  shall  issue  a  quarterly  report  listing  the  changes  considered  unacceptable. 
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APPENDIX  V 

SDM  QUALIFICATION  CARD 


Name 


Core  Competency  -  provide  evidence  of  an  understandinq  (completed  traininq  /  colleqe 

Division 

Director 

Signature 

Date 

coursework  /  technical  papers,  etc)  or  demonstrate  an  understandinq  of  the  followinq 

competencies  to  a  SEA  05D  Division  Director 

Knowledge  of  Virtual  SYSCOM  Technical  Authority  Instructions  and  Procedures 

Knowledge  of  NAVY  NAVSEA  and  SEA  05  Mission,  Values,  Structure,  Customers,  Guiding 
Principles  and  Processes 

Basic  knowledge  of  warfare  doctrine  (Navy  Doctrine  Library  System) 

Individual  and  Team  Performance  Skills  (self-direction,  interpersonal  relations,  technical 
competence  and  integrity,  positive  attitude,  continuous  learner,  foundation  leadership  skills, 
etc.) 

Oral,  written,  and  computer-based  communication  skills.  (Provide  examples) 

Analytical  skills  (identify  problems,  root  causes,  recommended  solutions,  etc.) 

Knowledge  of  Project  Management  skills 

Knowledge  of  Risk  Management  skills 

Knowledge  of  Systems  Engineering  (e.g.,  Requirements  analysis,  Functional  allocation,  etc.) 

Knowledge  of  design,  procurement,  operations,  and  support  of  surface  ship  systems  and 
components 

Knowledge  of  commercial  shipbuilding  standards,  design  practices,  and  ABS  SVR  and  HSC 

Knowledge  of  military  shipbuilding  standards,  design  practices,  and  ABS  and  HSNC 

Knowledge  of  Naval  Architecture  &  Marine  Engineering  through  class  work  or  a  working 
knowledge  of  SNAME  publication  Principles  of  Naval  Architecture  and  publication  Marine 
Engineering 

Knowledge  of  Warfare  Systems  Engineering  Principles  and  Processes  (System  and 
subsystem  Interface  definition/control,  etc.) 

Knowledge  of  System  of  Systems  Integration  techniques 

Knowledge  of  Customer  Oriented  Product  Development  (Business  Planning,  IPPD,  Logistics, 
etc.) 

Knowledge  of  Warfighting  Systems  Engineering  Hierarchy  and  Technical  Authority  Policy, 
including  use/development  of  technical  requirements,  standards,  and  tools 

Knowledge  of  Detail,  Performance-based  and  Hybrid  (e.g.,  System)  Specifications 
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Core  Competency  -  provide  evidence  of  an  understanding  (completed  traininq  /  colleqe 

Division 

Director 

Signature 

Date 

coursework  /  technical  papers,  etc)  or  demonstrate  an  understanding  of  the  following 

competencies  to  a  SEA  05D  Division  Director 

Knowledge  of  the  Total  Ship  System  Engineering  process  (HSI,  safety,  reliability,  etc.), 
particularly  the  principles  of  IPPD  applied  to  Design  for  Warfighting,  Design  for  Producibility, 
and  Design  for  Ownership 

Knowledge  of  Ship  Total  Ownership  Costs  and  Estimating  Methods 

Ability  to  support  contract  administration  (tasking,  money  flow,  etc.) 

Knowledge  of  Navy  Working  Capital  Fund  (NWCF)  and  private  sector  design  consortia 
business  practices 

Knowledge  of  RDT&E  and  Acquisition  Policy  and  Processes 

Knowledge  of  Configuration  Management  practices 

Ability  to  plan,  coordinate,  and  manage  complex  systems  development  (concept  studies, 
requirements  definition,  spec,  development,  interface  definition,  design  cert.,  etc.)  and  support 
programs  involving  interaction  with  a  variety  of  organizations 

Certifications 

Division 

Director 

Signature 

Date 

DAWIA  APC  membership 

DAWIA  SPRDE  Level  III  career  field  certification 

DAWIA  Program  Management  Level  II  career  field  certification 
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Interviews  -  meet  with  the  current  incumbent  of  the  followinq  positions  to  discuss  the 

Signature 

Date 

relationship  between  the  individual  and  the  SDM.  Discuss  lessons  learned  as  well  as  new 

processes  and  technoloqies  within  the  area  of  expertise. 

Human  Systems  Integration  TWH  (equivalent  such  as  the  IWS  HSI  TWH) 

Waterfront  CHENG 

Arrangements  -  Surface  Ships  TWH 

Damage  Control,  Fire  Fighting,  Recoverability,  Personnel  Protection  TWH 

Environmental  Requirements  and  Regulations  TWH 

Hydrodynamics  TWH 

Machinery  -  Climate  Control  Systems  TWH 

Machinery  -  Controls,  Networks  and  Monitoring  TWH 

Machinery  -  Electrical  Systems  TWH 

Machinery  -  Propulsion  and  Power  Systems  TWH 

Machinery  -  Weapons  Handling  and  Aviation  Support  TWH 

Materials  -  Coatings  and  Corrosion  Control  TWH 

Occupational  Safety  and  Health  Requirements  and  Regulations  TWH 

Product  Data  Integration/Exchange  TWH 

Reliability,  Maintainability,  and  Availability  TWH 

Ship  Survivability  TWH 

Structural  Integrity  TWH 

System  Safety  TWH 

Weight  Control  and  Stability  TWH 

Surface  Ship  Combat  and  Weapons  Control  TWH 

Topside  Design  TWH 

Business  Financial  Manager 

Cost  Engineer  from  SEA  05C 

Program  Manager  or  Deputy  Program  Manager  from  PEO-Ships 
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Interviews  -  meet  with  the  current  incumbent  of  the  followinq  positions  to  discuss  the 
relationship  between  the  individual  and  the  SDM.  Discuss  lessons  learned  as  well  as  new 
processes  and  technoloqies  within  the  area  of  expertise. 

Signature 

Date 

Program  Manager  or  Deputy  Program  Manager  from  PEO-IWS 

Once  the  above  sections  are  complete,  schedule  an  interview  with  SEA  05D/V  Technical  Director  and  Group 
Head: 

Signature  of  Technical  Director  Date 

Signature  of  Group  Head  Date 
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APPENDIX  W 

OTHER  DESIGN  PARTICIPANTS 

W.1  DEPUTY  SHIP  DESIGN  MANAGER. 

In  the  case  of  major  or  multiple  concurrent  designs,  the  SDM  may  be  assigned  a  deputy.  This  position  has  proven 
to  be  justified  for  a  major  ship  in  Contract  Design,  as  past  experience  shows  that  a  large  portion  of  the  SDM’s 
time  is  devoted  to  communication  outside  the  Design  Team.  Thus,  while  the  SDM  is  occupied  with  external 
communications  and  reporting  design  progress  to  higher  management,  an  internal  representative  is  needed  to 
direct  and  coordinate  the  project  operations.  Deputy  SDMs  are  individuals  whose  training  and  experience  have 
been  similar  to  those  of  an  SDM.  They  serve  as  representatives  of  the  SDM  and  SEA  05  in  all  matters  and  are  to 
be  accorded  the  same  respect  and  trust.  Their  attendance  at  a  meeting  or  conference  in  lieu  of  the  SDM  should 
not  be  considered  a  slight  to  participants.  The  DSDM  is  empowered  to  act  in  the  absence  of  the  SDM  in  all 
matters  and  is  held  accountable  for  decisions  made.  However,  they  do  not  have  technical  warrants.  Typical 
duties  include: 

•  Planning  the  design  schedule 

•  Defining  the  design  task  requirements 

•  Translating  the  task  requirements  into  WTAs 

•  Developing  and  establishing  technical  and  financial  tracking  systems 

•  Coordinating  design  participants  who  are  outside  the  NAVSEA  structure 

•  Directing  the  overall  technical  activities 

W.2  DESIGN  INTEGRATION  MANAGER. 

Depending  upon  the  design  scope,  complexity,  priority,  and  personnel  availability,  a  DIM  may  be  assigned  on  a 
full  time  basis.  The  DIM,  often  the  existing  PNA,  will  generally  be  responsible  for  integrating  the  various 
elements  of  the  design  and  configuration  control  during  the  Preliminary  and  Contract  Design  phases.  Specific 
duties  include: 

•  Maintaining  technical  consistency  among  diverse  disciplines  contributing  to  the  design 

•  Amplification  and  promulgation  of  the  ship  design  philosophy  and  constraints 

•  Review  of  draft  SOWs 

•  Review  of  technical  products  to  ensure  that  final  design  products  are  internally  consistent  and  meet  the 
design  engineering  standards,  CDD  requirements,  and  the  total  system  integration/optimization  aspects 
in  conjunction  with  the  SEMs 

•  Development  of  margin  and  allowance  policies,  design  budgets  and  design  standards,  as  well  as  the 
monitoring  and  control  of  margins  and  allowances 

•  Identification  of  areas  of  high  technical  risk 

•  Development  and  implementation  of  CM  procedures 

•  Preparation  of  the  design  histories 

The  DIM  is  often  responsible  for  total  ship  risk  assessment  and  preparation  of  the  risk  management  plan  elements. 
The  DIM  works  with  the  Specification  Manager  in  the  development  of  the  Ship  Specifications. 
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Integration  is  an  interactive  and  iterative  process,  dependent  upon  trade  studies  and  analyses  performed  by 
specialists  in  the  various  relevant  technical  disciplines.  The  integration  objective  is  to  achieve  the  “best” 
combination  of  subsystem  performance  that  enables  accomplishment  of  desired  capabilities  of  the  total  ship 
system  within  the  bounds  of  defined  economic,  human  performance,  and  technological  constraints.  Within  this 
context,  the  DIM  will  be  responsible  for  the  following  additional  tasks: 

•  Perform  engineering  analyses  of  customer  mission  and  performance  requirements  to  define  whole  ship 
attributes  in  engineering  terms 

•  Perform  engineering  studies  leading  to  the  allocation  of  whole  ship  attributes  to  ship  systems  in  terms 
of  design  direction,  performance,  configuration,  space  and  weight,  and  arrangement 

•  Perform  design  and  engineering  studies  to  identify  the  degree  of  ship  systems  integration  required  to 
meet  the  ship  mission 

•  Perform  analyses  to  assure  that  all  design  proposals  (or  changes)  affecting  whole  ship  performance  and 
other  functional  systems  meet  established  requirements  and  constraints,  properly  interfaced  in  respect 
to  the  various  whole  ship  “ilities” 

•  Perform  continual  review  and  analysis  of  the  developing  design  to  assure  that  the  ship  is  functionally 
balanced  and  integrated  in  terms  of  distribution  and  location  of  functions,  seaworthiness  and  sea 
kindliness,  mission  suitability  (reaction,  survivability),  and  performance 

•  Identify  ship  system  characteristics  and  capabilities  of  alternative  system  configurations 

W.3  SHIP  CONCEPTS  MANAGER. 

The  SCM  is  directly  responsible  for  establishing  the  foundation  upon  which  a  successful  ship  design  project  and 
final  design  package  can  be  built.  In  that  context,  a  typical  effort  undertaken  by  the  SCM  is  to  support  the  JCIDS- 
defined  pre -Milestone  A  tasks  associated  with  the  development  of  a  CBA  and  ICD  and  sometimes  the  AoA.  He 
then  translates  the  insights  and  knowledge  gleaned  from  that  involvement  to  later  stages  of  the  program,  so  as  to 
further  the  SDM’s  ability  to  be  fully  responsive  to  those  analyses. 

W.4  PROJECT  NAVAL  ARCHITECT. 

A  PNA  may  be  assigned  to  assist  the  SDM.  The  PNA  reports  to  the  DIM  and  provides  assistance  with  vessel 
design  integration  and  configuration  control.  The  primary  focus  areas  for  the  PNA  relate  to  hull  form,  hull 
strength,  hydrodynamics,  sea  keeping  and  survivability,  stability,  structures,  arrangements,  habitability,  lifesaving 
and  mooring  systems,  and  cargo  handling  systems.  The  PNA  is  the  principal  for  review  and  oversight  of  the 
Shipbuilder’s  effort  for  the  focus  areas  above  and  for  deck  systems  development.  The  PNA  coordinates  review 
by  the  government  team  members  at  the  system  and  subsystem  levels. 

W.5  PROJECT  MARINE  ENGINEER. 

A  PME  may  be  assigned  to  assist  the  SDM.  The  PME  reports  to  the  DIM  and  provides  assistance  with  machinery 
design  integration  and  configuration  control.  The  primary  focus  areas  for  the  PME  relate  to  propulsion,  power 
generation,  and  auxiliary  systems.  The  PME  is  the  principal  for  review  and  oversight  of  the  Shipbuilder’s  effort 
for  systems  development  and  coordinates  review  by  the  government  team  members  at  the  system  and  subsystem 
levels. 
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W.6  SYSTEM  ENGINEERING  MANAGERS. 

SEMs  integrate  and  represent  systems  level  elements  of  the  ship  design  such  as  hull  systems,  machinery  systems, 
combat  systems,  aviation,  C4ISR,  and  others,  as  the  design  demands.  Each  SEM  is  responsible  to  the  SDM, 
associated  SIM  and  TWHs,  and  their  respective  Group  Directors  for  providing  a  fully  developed  and  properly 
integrated  system  that  meets  the  operational  requirements  of  the  ship  design.  SEMs  assume  the  responsibilities  of 
the  functional  groups  they  represent  to  make  priority,  technical,  and  financial  decisions  that  are  consistent  with 
the  established  line  management  technical  policies,  practices,  and  standards.  More  specifically,  for  a  given  ship 
design  they  are  responsible  for  planning,  management,  and  all  technical  activities;  for  keeping  their  portion  of  the 
design  within  the  allocated  weight  and  fiscal  budgets  without  sacrificing  technical  performance;  for  ensuring  that 
final  products  meet  accepted  design  criteria  and  practices  and  meet  the  operational  requirements  as  well  as  whole 
ship  requirements;  and  for  administration  and  control  of  funds  within  their  respective  areas  of  responsibility. 

W.7  SPECIFICATION  MANAGER.  SPECIFICATION  TASK  MANAGER.  SPECIFICATION  EDITOR. 
AND  REQUIREMENTS  TRACEABILITY  MANAGER. 

SEA  05S  is  responsible  for  establishing  policy  and  procedures  for  developing  program-unique  specifications  and 
managing  the  development  of  Ship  Specifications  and  processes  for  Navy  ship  and  submarine  acquisition 
programs.  A  SEA  05S  representative,  as  the  Specification  Manager,  normally  oversees  Ship  Specification 
preparation  including  scheduling,  circulation,  and  issuing  the  associated  planning  documents. 

The  Specification  Task  Manager’s  (STM’s)  primary  responsibility  is  technical  integration  of  the  Ship 
Specification.  This  includes  integration  of  reference  documentation  such  as  military  and  commercial  standards. 
The  STM  must  be  familiar  with  all  aspects  of  the  ship  design.  The  STM  leads  a  small  Specifications  Team  that 
includes  the  Specification  Editor,  the  Requirements  Traceability  Manager  (RTM),  and  the  Data  Manager  for  DRL 
development.  The  STM  and  Specifications  Team  are  jointly  responsible  for  requirements  traceability,  ensuring 
that  specification  requirements  are  measurable  and  testable,  preparation  of  data  inputs  for  the  DRL,  and 
coordination  of  the  change  control  process. 

The  Specification  Editor  performs  the  administrative  editing  tasks  associated  with  development  of  the 
Shipbuilding  Specification,  including  establishing  and  periodically  updating  the  baseline  Shipbuilding 
Specification  in  the  IDE,  providing  necessary  specification  information  to  the  Requirements  Traceability  Manager 
(RTM),  operating  visual  aids  during  the  Reading  Sessions  and  ensuring  specification  changes  have  been  properly 
processed.  The  Specification  Editor,  as  a  member  of  the  Specifications  Team,  reports  to  the  STM. 

The  RTM  is  responsible  for  managing  the  flow  down  of  requirements  (traceability)  through  each  phase  of  the 
program  and  managing  the  software  (like  the  Dynamic  Object  Oriented  Requirements  System)  being  used  to 
capture,  analyze,  and  trace  the  requirements.  The  RTM  obtains  periodically  the  latest  revisions  to  the  Ship 
Specification  from  the  Specification  Editor  to  ensure  continuous  traceability  of  requirements  evolution. 

The  Data  Manager  is  responsible  for  preparation  and  processing  of  the  DRL  and  corresponding  Data  Items  (DIs) 
for  all  tasking  statements  in  the  Shipbuilding  Specification.  The  Data  Manager,  as  a  member  of  the  Specifications 
Team,  reports  to  the  STM  and  also  normally  to  the  Program  Logistics  Manager. 
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W.8  ENVIRONMENTAL.  SAFETY  AND  OCCUPATIONAL  HEALTH  AND/OR  SAFETY  MANAGER. 

An  ESOH  and/or  Safety  Manager  will  be  assigned.  A  separate  Principal  for  Safety  may  also  be  designated  to 
handle  explosives  safety  including  Weapons  System  Explosives  Safety  Review  Board  (WSESRB)  certification. 
Note  that  for  NAVSEA  Programs  the  Principal  for  Safety  may  assume  both  the  ESOH  and  Safety  Manager  roles. 
The  Program  must  ensure  the  design  meets  all  system  safety  requirements  and  that  all  mishap  (environmental, 
safety,  and  occupational  health)  and  risks  are  identified  for  the  full  life  cycle  of  the  ship  per  MIL-STD-882.  The 
Safety  Manager  will  propose  mitigation  plans  to  reduce  unacceptable  risks  identified  in  the  Specifications, 
Shipbuilder  concepts,  Detail  Design,  process  development,  production,  system  test,  and  evaluation  during  the  life 
cycle  of  the  ship.  Lessons  learned  from  similar  systems  and  systems  of  systems  will  be  used  during  these 
evaluations.  Risks  will  be  identified  through  a  working  group  and  handled  through  the  formal  risk  management 
process. 

W.9  TASK  LEADERS. 

TLs  are  part  of  the  technical  core  of  the  Design  Team  and  are  responsible  to  the  SEMs  for  the  execution  of  their 
parts  of  the  various  tasks.  They  are  designated  by  and  are  jointly  responsible  to  the  TWHs  and  their  cognizant 
SEM  for  technical  content.  They  are  responsible  to  the  SEM  also  for  adherence  to  the  schedule  within  allocated 
funds  and  manpower,  and  final  product  development  of  their  tasks.  They  provide  the  SOWs  for  their  respective 
tasks;  coordinate  and  monitor  supporting  functional  codes  as  the  design  develops;  ensure  that  concurrent  RDT&E 
programs  are  compatible  with  their  respective  design  areas;  ensure  that  all  reports,  studies,  and  products  prepared 
by  other  activities  that  are  forwarded  for  review  and  comment  get  proper  staffing;  and  make  certain  that  an 
adequate  technical  response  is  formulated.  The  TL  is  the  risk  manager  for  any  high  or  moderate  risk  areas  in  her 
area  of  responsibility. 

W.10  INTERFACING  TECHNICAL  WARRANT  HOLDERS  AND  OTHER  SUBJECT  MATTER 
EXPERTS. 

Selected  TWHs  and  other  SMEs  will  be  needed  to  review  the  technical  products  and  participate  in  certification  of 
the  ship  and  or  systems.  SDMs  and  SIMs  must  ensure  timely  and  productive  participation  by  the  TWHs  and  other 
experts  from  the  NAVSEA,  Naval  Air  Systems  Command  (NAVAIR),  Space  and  Warfare  Systems  Command 
(SPAWAR),  Naval  Supply  Systems  Command  (NAVSUP),  ABS,  MSC,  Bureau  of  Medicine  and  Surgery 
(BUMED),  Naval  Safety  Center,  Board  of  Inspection  and  Survey  (INSURV),  PEO  C4I,  PEO  IWS,  Marine  Coips 
Systems  Command,  Marine  Corps  Combat  Development  Center,  Naval  Laboratories,  U.S.  Coast  Guard  (USCG) 
and  other  applicable  activities.  These  may  or  may  not  serve  as  SEMs  or  TLs.  Relationships  should  be  formalized 
and  written  tasking  provided  no  later  than  conduct  of  the  AoA.  In  the  past,  failure  to  establish  and  maintain 
agreement  on  required  budget,  personnel  assignments,  deliverables,  and  schedule  have  repeatedly  resulted  in 
delay  and  disruption  of  the  design  process. 

Efforts  have  begun  to  establish  a  “Virtual  Systems  Command.”  These  have  included  establishment  of  a  topside 
integration  council,  joint  SYSCOM  engineering  guide,  joint  air-ship  integration  guide,  and  design  principles. 
SDMs  and  SIMs  should  become  familiar  with  these  references  as  they  apply  to  a  specific  project. 
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As  established  in  Virtual  SYSCOM  Joint  Instruction  22A  (NAVSEAINST  5400.97C)  ( hyperlink ),  technical 
warrants  provide  the  authority,  responsibility,  and  accountability  to  establish,  monitor,  and  approve  technical 
products  and  policy  in  conformance  to  higher-tier  policy.  Such  individuals  are  entrusted  and  empowered  to  make 
technically  sound  engineering  decisions,  and  must  do  so  with  integrity  and  discipline.  This  allows  decisions  to  be 
made  in  a  timely  and  responsive  manner,  not  requiring  excessive  review  and  oversight.  The  NAVSEA 
Commander  is  the  technical  authority  for  ships,  weapons  systems,  and  their  supporting  infrastructure.  This 
technical  authority  is  delegated  to  NAVSEA  via  SECNAVINST  5400. 15C  (hyperlink).  NAVSEA,  in  turn, 
assigns  warrants  to  individuals  within  their  areas  of  technical  responsibility.  These  include  SDMs,  SIMs,  TWHs, 
CHENGs,  warfare  systems  engineers/chief  systems  engineers  (CSEs),  and  cost  engineering  managers.  TWHs 
will  make  authoritative  decisions  on  technical  matters,  engineering  practices,  and  processes  related  to  the  design, 
development,  construction,  testing,  repair,  operation,  in-service  support,  and/or  disposal  of  platforms,  systems,  or 
tools.  They  also  will  ensure  that  sound  technical  decisions  are  made  in  a  manner  that  complies  with  higher-tier 
requirements,  meets  the  needs  of  the  responsible  programmatic  authority,  and  addresses  risks,  alternatives,  and 
trade-offs  as  appropriate. 

SDMs  and  SIMs  lead  systems  engineering  efforts  for  assigned  platforms/systems,  and  are  warranted  to  make 
integration  decisions  for  them.  SDMs  lead  the  technical  efforts  of  the  Program  Offices,  including  compliance 
with  DoD/SECNAV  5000  series  guidance. 

In  NAVSEA  CHENG  letter  “Expectations  for  Technical  Warrant  Authorities”  serial  TAB/010  of  17  March  2008, 
all  NAVSEA  TWHs  including  SDMs  and  SIMs  are  directed  to  ensure  that  they  promptly  notify  their  DWO  of 
significant  or  unusual  events  in  their  warranted  technical  areas.  TWHs  are  fully  accountable  to  their  DWO  and 
must  keep  their  DWO  informed  of  all  significant  events. 

DWOs  are  directed  to  ensure  that  they  maintain  regular  contact  with  their  assigned  TWHs  to  facilitate  an  open 
dialog  on  issues  of  significance,  maintain  overall  situation  awareness,  and  understand  when  senior  management 
help  is  needed  to  ensure  technical  issues  get  resolved.  At  a  minimum,  DWOs  shall  discuss  issues  of  concern  with 
TWHs  at  least  monthly.  While  monthly  is  established  as  a  minimum  periodicity,  DWOs  must  consider  many 
factors  including  complexity  of  issues,  TWH  experience,  and  the  availability  of  a  support  network  to  assist 
individual  TWHs  when  determining  the  frequency  of  contact.  DWOs  should  also  ensure  that  significant  issues 
are  promptly  reported  to  the  NAVSEA  CHENG  to  ensure  that  the  broader  Research  and  Systems  Engineering 
Competency  is  engaged  as  appropriate  to  assist  in  timely  resolution. 

SEA  05D  ltr  5400  Ser  05D/031  of  13  April  2011  “FY1 1  SEA  05D  Technical  Authority  Assessment  Plan” 

( hyperlink ),  provides  for  the  annual  assessment  of  SEA  05D  warrant  holders  as  required  by  NAVSEA  ltr  Ser 
05/014,  22  February  2010,  Annual  Qualification  Assessment  of  Technical  Warrant  Holders  in  the  NAVSEA 
Research  and  Systems  Engineering  Competency  (hyperlink). 

W.11  COST  ESTIMATORS. 

Cost  estimating  is  critical  to  the  performance  of  the  AoA,  subsequent  milestones,  and  source  selection.  Higher 
authority  needs  to  assess  cost  versus  performance  and  establish  suitable  budgets.  As  the  designated  TWHs,  SEA 
05C  personnel  normally  perform  cost  estimating  for  ship  programs. 

The  SDM  has  the  lead  responsibility  for  providing  design  information  to  SEA  05C  for  the  development  of 
program  cost  estimates  and  to  the  DoD  or  Navy  Cost  Analysis  Improvement  Group  (CAIG)  for  the  conduct  of 
their  independent  cost  assessments  and  estimates  to  support  the  milestone  reviews.  SDMs  participate  in  SEA  05C 
cost  estimate  peer  reviews  as  the  technical  authority  for  the  design  characteristics  used  in  development  of  the 
estimate. 


W-5 


S9800-AC-M  AN-010 


The  SDM  must  identify  his  SEA  05C  counterpart,  who  is  identified  as  the  Cost  Team  Leader  for  the  SDM’s  ship 
design  project,  early  in  each  phase  and  establish  a  close  working  relationship.  It  has  become  common  practice  for 
the  SDM  to  continue  to  support  SEA  05C  beyond  the  submission  of  design  information  -  conducting  ship  work 
breakdown  structure  (SWBS)  by  SWBS  reviews  of  the  design  data  submitted  and  the  associated  assumptions  for 
cost  estimating. 

W.12  GOVERNMENT  FURNISHED  EQUIPMENT  AND  INFORMATION  MANAGERS. 

GFE/GFI  managers  (also  known  as  PARMs)  must  be  brought  into  the  design  process  by  the  SDM  to  verify  the 
performance;  space;  weight;  manpower,  personnel,  and  training;  and  services  impacts  of  their  systems.  The 
Program  Office  will  formalize  agreements  with  each  PARM  for  budget,  delivery  schedule,  and  the  development 
of  installation  control  drawings  and  other  GFI.  GFE  and  GFI  changes  and  delays  in  deliveries  have  caused 
significant  disruptions  to  past  shipbuilding  programs. 

The  SDM  is  responsible  for  verifying  that  appropriate  GFI  is  properly  described,  listed,  and  scheduled  within  the 
RFP.  Before  GFI  is  forwarded  to  the  contractor,  the  SDM  is  responsible  for  reviewing  it  to  ensure  it  does  not 
conflict  with  the  existing  contract  baseline.  If  conflicts  are  identified,  the  SDM  shall  work  with  the  Program 
Office  and  PARMs  to  either  change  the  GFI  or  the  ship  contract  baseline  as  appropriate. 

W.13  NAVAL  REACTORS  (SEA  08). 

SEA  08  is  the  organization  responsible  for  management  of  all  aspects  of  design,  acquisition,  and  maintenance 
pertaining  to  nuclear  propulsion  in  U.S.  Naval  ships  and  submarines.  They  define  maintenance  requirements  for 
reactor  plant  systems  and  components  including  modernization  and  configuration,  and  provide  oversight  to  ensure 
compliance  with  established  requirements  at  facilities  approved  for  nuclear  related  industrial  work. 

W.14  REACTOR  PLANT  PLANNING  YARD. 

Reactor  Plant  Planning  Yard  (RPPY)  is  the  organization  responsible  for  managing  the  nuclear  portion  of  the 
Integrated  Management  Plan.  This  includes  evaluating  and  implementing  reactor  plant  changes  proposed  by  the 
Shipbuilders,  ship,  and  Commander  Naval  Air  Forces  (CNAF).  The  RPPY  is  responsible  for  incorporating 
reactor  plant  lessons  learned  into  the  IMP. 

W.15  NAVAL  SURFACE  WARFARE  CENTERS. 

Naval  Surface  Warfare  Centers  (NSWCs)  are  the  Navy’s  lull  spectrum  research,  development,  T&E,  engineering, 
and  Fleet  support  centers  for  ship  hull,  mechanical  and  electrical  systems,  surface  ship  combat  systems,  coastal 
warfare  systems,  and  other  offensive  and  defensive  systems  associated  with  surface  warfare. 

W.16  REGIONAL  MAINTENANCE  CENTERS. 

Regional  Maintenance  Centers  (RMCs)  are  primarily  responsible  for  executing  assigned  maintenance  for  ships  in 
their  geographical  region.  The  RMC  has  access  to  both  standard  and  non-standard  repair  organizations.  The 
focus  of  the  RMC  is  to  achieve  coordinated  utilization  of  resources,  maintain  adequate  industrial  capacity,  and 
arrange  for  the  industrial  facilities  needed  to  support  projected  work  requirements. 

The  RMCs  broker  work  items  screened  by  the  Type  Commander  (TYCOM)  to  the  appropriate  organization  or 
activity  for  accomplishment.  The  RMC  provides  direct  support  to  Fleet  and  TYCOMs  in  matters  of  waterfront 
technical  assistance,  maintenance  training,  and  logistics  services  associated  with  the  installation,  operation, 
maintenance,  and  readiness  of  shipboard  equipment  and  systems.  They  promote  Fleet  readiness  and  maintenance 
self-sufficiency  in  shipboard  systems  and  equipment  through  direct  technical  help  in  troubleshooting, 
maintenance  and  repair,  on-the-job  maintenance  training,  logistics  reviews,  and  technical  documentation  support. 
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“Regional  Repair  Centers”  focus  on  a  particular  product  line  (e.g.,  motors)  or  technology  (e.g.,  machinery). 

These  shops  were  created  to  increase  the  proficiency  level  of  maintenance  personnel  by  focusing  each 
maintenance  group  on  a  particular  piece  of  equipment  or  technology. 

Nuclear  Regional  Maintenance  Department  (NRMD),  a  subset  of  the  RMC.  provides  project  management, 
planning,  training,  and  radiological  control  services  to  accomplish  nuclear  maintenance,  modernization,  and 
repairs.  Some  key  areas  where  their  support  is  essential  for  success  are  radiological  support  for  primary  detector 
alignment,  radioactive  waste  handling,  and  RADIAC  calibration  support. 

The  RMC  CHENG  is  responsible  and  accountable  for  all  engineering,  technical  work,  and  technical  decision¬ 
making  accomplished  by  his  or  her  assigned  activities  as  defined  by  NAVSEAINST  5400.95E.  Ship  and  work 
period  specific  MOAs  are  issued  to  delineate  agreements  between  the  RMC  CHENG  and  other  activities  involved 
in  the  construction,  conversion,  and  refit  or  repair  work. 

W.17  INTEGRATED  DESIGN  ENGINEERING  ACTIVITY. 

The  Integrated  Design  Engineering  Activity  (IDEA)  is  an  integrated  team  composed  of  the  three  primary  aircraft 
carrier  repair  and  modernization  activities  (Northrop  Grumman  Newport  News  (NGNN),  Portsmouth  Naval 
Shipyard  (PSNSY),  and  Norfolk  Naval  Shipyard  (NNSY)).  The  IDEA  has  changed  traditional  planning  yard 
responsibilities  and  assigns  planning  products  development  to  the  executing  yards  for  aircraft  carriers  undergoing 
availabilities.  Under  the  IDEA,  the  executing  yard  bears  sole  responsibility  for  all  design,  planning,  and 
execution  for  the  assigned  aircraft  carriers. 

W.18  NAVAL  SUPERVISING  AUTHORITY. 

The  Naval  Supervising  Authority  (NSA)  is  that  maintenance  activity  with  overall  responsibility  for  the  proper 
planning  and  execution  of  the  work  package  during  a  CNO  -  scheduled  availability,  including  all  contractor  and 
Alteration  Installation  Team  (AIT)  work.  The  function  of  the  NSA  is  defined  in  the  Fleet  Modernization 
Program  Management  and  Operations  Manual  (NAVSEA  SL720-AA-MAN-010).  The  NSA  is  also  accountable  to 
NAVSEA  regarding  the  conduct  of  all  work  covered  by  the  FMP. 

W.19  CARRIER  AND  FIELD  SERVICE  UNIT. 

The  technical  representative  of  NAVAIR  and  Naval  Air  Warfare  Center  Aircraft  Division,  Lakehurst,  NJ 
(NAVAIRLAKEHURSTACDIV)  in  all  matters  which  concern  shipboard  catapult,  arresting  gear,  Visual  Landing 
Aid  (VLA)  systems,  Aviation  Fuels  (AVFUELS),  and  shore-based  arresting  gear.  Carrier  and  Field  Service  Unit 
(CAFSU)  team  members  are  strategically  and  permanently  located  in  Field  Offices  at  aircraft  carrier  homeports 
and  repair  facilities.  CAFSU  is  responsible  for  technical  oversight  during  installation  operations  of  Aircraft 
Launch  and  Recovery  Equipment  (ALRE)  systems  installed  on-board  all  CV/CVNs  and  at  shore  installations. 
CAFSU  provides  onsite  technical  expertise  to  the  CNAF.  CAFSU  team  maintains  technical  liaison  with  naval 
shipyards,  ship  repair  facilities  in  support  of  installation,  operation,  overhaul,  maintenance,  repair,  testing,  and 
certification  of  ALRE,  VLA,  and  AVFUELS. 

W.20  NAVAIR  WARFARE  CENTER  VOYAGE  REPAIR  TEAM. 

This  is  the  activity  responsible  to  provide  depot  level  maintenance  and  emergent  repair  services  to  a  variety  of 
ALRE,  VLA,  and  Air  Capable  Ship  Aeronautical  Equipment  (ACSAE).  This  maintenance  service  is  provided  to 
operational  Fleet  activities  worldwide  and  to  shore  based  naval  activities.  These  services  include: 

•  Scheduled  and  unscheduled  maintenance 

•  Repair  or  overhaul  of  installed  aviation  equipment  and  support  systems 

•  Manufacturing  of  repair  assemblies  and  equipment  Installation  of  modernization 
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The  Voyage  Repair  Team  (VRT)  organization  and  supporting  infrastructure  provide  the  aircraft  carrier 
maintenance  community  with  a  trained  and  ready  resource  to  correct  deficiencies  that  directly  impact  the  safety  of 
flight  and  the  ship’s  mission. 

W.21  CARRIER  TEAM  ONE. 

Carrier  Team  One  is  a  group  of  experienced  aircraft  carrier  maintenance  professionals  chartered  by  NAVSEA  in 
1994  to  improve  maintenance  processes  and  strategies  associated  with  aircraft  carrier  maintenance.  Its 
membership  of  ship’s  force,  Shipbuilder,  and  other  supporting  organizations  provides  new,  unique  perspectives  of 
the  maintenance  process.  Team  One  is  a  collaborative  effort  led  by  PMS  312,  SEA  08,  and  CNAF.  The 
initiatives  are  driven  by  deck-plate  experience.  Implementation  is  guided  and  assisted  by  the  Executive  Steering 
Committee.  Team  One’s  puipose  is  to  define,  champion,  and  improve  cross-organizational  processes  for  the 
planning  and  execution  of  carrier  availabilities.  Team  One  provides  a  structure  for  the  management  and  long¬ 
term  systematic  improvement  of  cost,  schedule,  and  quality  performance.  The  means  and  measures  for 
improvement  will  reflect  the  considerations  of  all  affected  parties,  including,  but  not  limited  to,  ship’s  force, 
TYCOMs,  shipyards/Shipbuilders  (public  and  private),  NAVSEA,  SPAWAR,  and  NAVAIR.  The  focus  of  Team 
One  is  the  integration  of  the  efforts  of  contributing  organizations  into  an  effective  total  process.  Team  One  is 
neither  a  technical  authority,  nor  a  substitute  for  the  proper  execution  of  assigned  responsibilities  or  process 
improvement  programs  internal  to  contributing  organizations.  Refer  to  the  Team  One  Manual  for  additional 
information. 

W.22  SHIP'S  FORCE. 

Ship’s  force  has  the  overall  responsibility  for  the  maintenance  and  operations  of  all  shipboard  systems  and 
equipment.  Each  ship  has  a  maintenance  organization  that  is  clearly  defined  in  the  Ship ’s  Organizational  and 
Regulations  Manual  (SORM).  In  addition  to  the  SORM,  ship’s  force  is  responsible  for  all  matters  related  to  the 
Maintenance  and  Material  Management  (3-M)  System  that  are  delineated  in  the  OPNAV  4790  series  instructions. 

W.23  NAVSEA  FIELD  REPRESENTATIVE’S  OFFICE. 

The  NAVSEA  Shipyard  Representative’s  Office  (NSRO)  is  responsible  for  independent  oversight  of  Shipbuilder 
non-nuclear  operations  for  adherence  to  NAVSEA  standards  and  requirements,  for  oversight  of  ship  safety,  for 
assisting  NAVSEA  in  working  with  the  Shipbuilders  to  resolve  issues  that  inhibit  first-time  quality  work,  and  to 
assist  improved  performance  by  Naval  Shipyards.  NSRO  responsibilities  also  apply  to  Shipbuilder  work  at 
remote  sites  and  include  those  of  engineering  field  representatives. 

Each  NSRO  will: 

•  Provide  independent  review  and  assessment  of  Naval  Shipyard/Shipbuilder  non-nuclear  operations 

•  Review  and  evaluate  test  procedures,  testing,  and  ship  conditions 

•  Assess  implementation  of  corporate  processes,  procedures,  and  requirements 

•  Assist  in  resolution  of  problems 

•  Assist  NAVSEA  in  understanding  process  problems  that  inhibit  timely  first-time  quality  during  ship 
repair  work 

•  Review  and  evaluate  the  shipyard/Shipbuilder’s  quality  assurance  (QA)  program  to  ensure  the  program 
results  in  the  requisite  quality  of  work 

•  Review  and  evaluate  engineering  including  compliance  of  technical  work  documents  with  NAVSEA 
requirements 
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W.24  NAVSEA  ENGINEERING  FIELD  REPRESENTATIVES. 

Engineering  Field  Representatives  (EFRs)  provide  independent  oversight  of  CHENGs  and  their  associated 
waterfront  maintenance  activities  engaged  in  engineering  and  the  exercise  of  technical  authority  for 
commissioned  ships.  EFRs  may  also  be  assigned  for  CHENGs  overseeing  ships  under  construction.  EFRs  are 
assigned  to  the  field  to  facilitate  communication  on  technical  issues  between  NAVSEA  SDMs,  Warrant  Holders, 
and  local  region’s  RMC,  TYCOM(s).  Responsibilities  include: 

•  Providing  independent  oversight  of  the  exercise  of  technical  authority 

•  Evaluating  and  assessing  implementation  and  compliance  with  NAVSEA  technical  requirements, 
standards,  processes,  and  policies 

•  Facilitating  collaborative  technical  communications  among  the  Navy  technical  community,  Fleet 
TYCOMs,  RMCs,  Naval  Shipyard/Shipbuilders,  and  other  waterfront  maintenance  activities 

•  Advising  NAVSEA  technical  leadership  and  engineering  management  on  significant  technical  issues 
and  technical  core  equities 

•  Providing  on-scene  assistance  and  independent  oversight  in  support  of  SDMs  and  other  TWHs 

•  Reviewing  and  processing  field  activity  trouble  reports 

W.25  INDEPENDENT  REVIEW  TEAMS. 

Conduct  of  design  and  technical  assessments  by  independent  review  teams  is  recommended  in  areas  where 
technical  risks  are  high.  Sources  of  independent  reviewers  include  “graybeards,”  academia,  professional 
organizations,  and  industry.  The  SDM  must  be  an  advocate  for  obtaining  funding  and  establishing  such  teams 
when  appropriate.  An  example  is  the  special  review  team  assembled  to  validate  the  use  of  the  “FREDYN”  ship 
motions  program  for  the  design  of  DDG1000,  which  has  a  novel  hull  form. 

W.26  UNITED  STATES  COAST  GUARD  AND  AMERICAN  BUREAU  OF  SHIPPING. 

All  shipbuilding  programs  now  minimize  the  use  of  military  specifications  and  standards.  Those  ships  crewed  by 
the  MSC  normally  make  maximum  use  of  commercial  standards  and  construction  practices.  They  are  required  to 
be  built  to  ABS  rules,  classed  by  ABS  and  under  USCG  and  Navy  standards  as  applicable.  MSC  ships  may  be 
enrolled  in  the  alternate  compliance  program  in  which  ABS  performs  the  majority  of  the  USCG  review  for  them. 
However,  anytime  a  deviation  from  the  USCG  regulations  is  requested,  ABS  will  forward  a  recommendation  to 
the  USCG,  the  flag  state  authority,  who  will  make  the  final  decision. 

NAVSEA  is  now  moving  away  from  the  use  of  ABS  Naval  Vessel  Rules  (NVR)  to  provide  the  core  technical 
standards  for  naval  combatants.  Further  detail  will  be  provided  in  the  next  revision  to  this  manual. 

Advance  contact  with  USCG  on  selected  compliance  issues  should  be  accomplished.  In  particular,  areas  should 
be  discussed  early  on  where  there  is  a  question  of  the  proposed  ship  not  meeting  the  letter  of  ABS  or  USCG 
standards.  A  significant  portion  of  an  SDM’s  time  can  be  spent  sorting  out  conflicts  between  the  requirements  for 
the  naval  mission  and  commercial  regulations.  Some  of  the  issues  may  be  avoided  by  getting  all  participants 
involved  early. 

W.27  SHIPBUILDERS,  INTEGRATORS.  AND  VENDORS. 

Consistent  with  the  acquisition  strategy,  industry  should  participate  in  the  design  process  early  to  gain  an 
understanding  of  Navy  requirements,  help  identify  cost  drivers,  incorporate  producibility  considerations,  and 
ensure  the  clarity  and  consistency  of  the  specifications.  The  SDM  must  work  closely  with  the  Program  Office  in 
determining  the  best  approach  for  industry  involvement. 
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Equipment  vendors  can  be  expected  to  approach  the  Program  Office  and  SDM  on  a  regular  basis  to  try  to 
influence  equipment  selection  and  development  of  the  specifications.  A  selective  approach  to  dealing  with 
vendors  should  be  developed.  For  example,  many  items  will  be  selected  by  the  Shipbuilder  as  part  of  the 
construction  phase,  so  send  the  vendors  to  prospective  Shipbuilders  instead  of  taking  the  briefings  directly. 
Similarly,  technologies  that  are  too  far  in  the  future  for  the  program  can  be  sent  to  the  ONR.  SDMs  must  guard 
their  time  carefully  and  not  let  it  be  monopolized  by  others’  marketing  efforts.  Listen  to  a  briefing  only  to 
become  smart  on  a  topic  of  interest,  not  because  someone  wants  to  talk  to  you.  Learn  to  just  say,  “no”  (thanks). 

Informational  briefings  from  Shipbuilders,  integrators,  and  vendors  can  and  should  be  taken  following 
consultation  with  the  NAVSEA  Contracting  Office.  Those  who  demonstrate  relevant  interest  should  be  invited  to 
attend  briefings  to  industry  prior  to  request  for  procurement  issues. 

Extra  care  must  be  employed  when  dealing  with  vendors  from  foreign  countries.  Design  information  for  the 
acquisition  program  usually  cannot  be  revealed.  Many  countries  have  data  exchange  agreements  with  the  U.S. 
and  these  may  be  employed  to  transfer  data.  An  individual  program  may  also  set  up  its  own  exchange  agreement 
established  through  the  Navy  International  Programs  Office.  SDMs  should  consult  SEA  05D/V  and  the  Program 
Office  before  any  involvement  with  a  foreign  company  or  government. 

W.28  SUPERVISORS  OF  SHIPBUILDING. 

SDMs  should  consider  employing  prospective  Supervisor’s  Offices  and  their  design  divisions  to  leverage  lessons 
learned  for  development  of  the  specifications.  This  will  also  help  establish  relationships  that  will  be  important 
following  DD&C  contract  award. 

W.29  SUPERVISOR  OF  SHIPBUILDING  CHIEF  ENGINEER. 

The  SUPSHIP  CHENG  is  responsible  and  accountable  for  all  engineering,  technical  work,  and  technical  decision¬ 
making  accomplished  by  their  assigned  activities  as  defined  by  NAVSEAINST  5400.95E.  Ship  and  work  period 
specific  MO  As  are  issued  to  delineate  agreements  between  the  SUPSHIP  CHENG  and  other  activities  involved  in 
the  construction,  conversion,  and  refit  or  repair  work. 

The  responsibilities  of  the  SUPSHIP  CHENG  for  managing  waterfront  engineering  include  the  following  major 
tasks: 

•  Maintaining  a  matrix  of  the  engineering  work  force,  under  the  control  of  the  SUPSHIP  CHENG, 
sufficient  in  scope  of  engineering  disciplines  and  technical  specialties  to  support  the  overall  program 
management  organization  and  Administrative  Contracting  Officer  (ACO)  by  providing  technical 
support  and  direction  to  meet  the  requirements  of  the  Technical  Authority  Warrant 

•  Assessing  manning  requirements  to  meet  the  requirements  of  the  warrant  in  relation  to  the  technical 
requirements  of  contracts 

•  Conducting  an  annual  Technical  Authority  Capability  Assessment  (TACA)  and  providing  the  TACA 
assessment  to  SEA  05,  the  SEA  05  Field  Representative  (when  assigned),  SEA  04,  and  SEA  04Z.  The 
TACA  will  include  recommendations  for  resolving  deficiencies  in  engineering  disciplines,  technical 
specialties,  or  manning  levels. 

•  Offering  support  and  recommendations  to  future  and  existing  ship  designs  and  participate  in  the  design 
process,  including  Ship  Specification  development  and  specification  readings 

•  Establishing  an  organization  and  process  for  adequate  oversight  where  a  contractor  and  government 
agency  personnel  are  performing  Planning  Yard  responsibilities 
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APPENDIX  X 
T-SHIP  CONOPS 


Executive  Summary 

Auxiliary  &  Special  Mission  ships  (commonly  referred  to  a  “T-SH1PS”)  are  generally  procured  for  the  MSC  via  a 
PEO  Ships  acquisition  program.  In  accordance  with  the  basic  tenets  of  the  NAVSEA  Competency  Aligned 
Organization,  SEA  05  (the  R&SE  Competency)  provides  all  required  engineering  and  technical  support  to  the 
NAVSEA  affiliated  PEOs.  SDMs  are  the  single  point  of  contact  with  Program  Offices  for  providing  this 
engineering  and  technical  support.  This  document  provides  process  guidance  and  defines  roles  and 
responsibilities  for  interactions  between  the  Program  Office  and  the  SDM  through  all  phases  of  T -SHIP 
acquisition.  It  is  not  intended  to  be  a  narrowly  prescriptive  document  but  to  provide  a  guide  based  on  proven  past 
practice  and  typical  T-SHIP  acquisition  strategies.  If  alternate  acquisition  strategies  are  used  the  guidance  will 
need  to  be  tailored. 

Key  areas  addressed  are: 

•  Interactions  with  other  TWHs 

•  Ship  Specification  review  and  approval 

•  Conduct  of  focused  technical  assessments  at  key  program  milestones 

•  Establishment  of  criteria  for  reviews 

•  Interactions  with  ABS 

•  Ship  certification 

The  processes  and  reviews  should  be  event  driven,  not  schedule  driven,  and  therefore  establishment  of  measurable 
entrance  and  exit  criteria  is  essential. 

The  goal  is  to  have  more  consistent  processes  in  order  to  better  plan  and  execute  the  design  management  of  T- 
SHIP  programs. 

This  document  provides  process  guidance  and  defines  roles  and  responsibilities  for  interactions  between  the 
Program  Office  and  the  SDM  throughout  all  phases  of  T-SHIP  acquisition.  It  was  developed  to  provide 
consistent  processes  in  order  to  better  plan  and  execute  the  design  management  of  T-SHIP  programs. 

SEA  05  has  issued  Attachment  (1)  which  establishes  the  SDM  as  the  sole  accountable  technical  authority  for 
these  ships. 

T-SHIPs  are  defined  as  Naval  Fleet  Auxiliary  Force,  Sealift,  Prepositioning  and  Special  Mission  ships  that  are 
procured  by  PEO  Ships  and  have  an  SDM  assigned.  In  the  case  of  designs  with  no  military  mission  like  the 
AGOR,  the  processes  will  be  tailored  as  appropriate  and  the  focus  is  expected  to  be  on  higher  risk  technical  and 
customer  critical  areas. 

X.1  INTRODUCTION/OVERVIEW  OF  A  T-SHIP  PROGRAM. 

T-SHIPs  are  generally  operated  by  MSC.  MSC  provides  the  sea  transportation  component  for  the  United  States 
Transportation  Command  (TRANSCOM).  TRANSCOM  operates  ships  that  provide: 

•  Combat  logistics  support  to  U.S.  Navy  ships  at  sea 

•  Special  mission  support  to  U.S.  government  agencies 

•  Prepositioning  of  U.S.  military  supplies  and  equipment  at  sea 

•  Ocean  transportation  of  Department  of  Defense  cargo  in  both  peacetime  and  war 


X-1 


S9800-AC-M  AN-010 


The  ships  are  typically  operated  by  civilian  mariners  or  commercial  contract  crews  and  may  have  a  detachment  of 
military  personnel.  The  primary  mission  of  MSC  is  to  provide  ocean  transportation  of  equipment,  fuel,  supplies 
and  ammunition  to  sustain  U.S.  forces  worldwide  during  peacetime  and  in  war  for  as  long  as  operational 
requirements  dictate.  During  a  war,  more  than  95  percent  of  all  equipment  and  supplies  needed  to  sustain  the  U.S. 
military  are  carried  by  sea. 

By  nature,  T-SHIP  programs  are  managed  somewhat  differently  then  U.S.  Navy  (USN)  Ship  programs  because 
the  end  user,  MSC,  has  different  requirements  and  needs  than  the  Navy  Fleet. 

T-SHIPS  are  organized  into  four  groups,  which  are: 

Naval  Fleet  Auxiliary  Force  -  The  ships  of  MSC’s  Naval  Fleet  Auxiliary  Force  (NFAF)  provide  fuel,  food, 
ammunition,  spare  parts,  and  other  supplies  to  Navy  ships.  NFAF  ships  enable  the  Navy  Fleet  to  operate  at  the 
highest  operational  tempo  possible.  NFAF  ships  provide  underway  replenishment  services  to  U.S.  Navy  ships 
worldwide  alleviating  the  need  for  them  to  constantly  return  to  port  for  supplies.  NFAF  is  composed  of  Fleet 
ocean  tugs,  fast  combat  support  ships,  Fleet  replenishment  oilers,  combat  stores  ships,  ammunition  ships,  Rescue- 
Salvage  Ships  and  Dry  Cargo/Ammunition  Ships  (T-AKE)  plus  two  hospital  ships  that  are  kept  in  a  reduced 
operating  status.  Besides  delivering  supplies  at  sea,  NFAF  ships  also  conduct  towing  and  salvage  operations  and 
serve  as  floating  medical  facilities. 

Special  Mission  -  MSC’s  Special  Mission  Program  controls  ships  that  provide  operating  platforms  and  services 
for  unique  U.S.  military  and  federal  government  missions.  Oceanographic  and  hydrographic  surveys,  underwater 
surveillance,  missile  flight  data  collection  and  tracking,  acoustic  surveys  and  submarine  support  are  just  a  few  of 
the  specialized  services  this  program  supports.  Special  mission  ships  work  for  several  different  U.S.  Navy 
customers,  including  the  Naval  Sea  Systems  Command  and  the  Oceanographer  of  the  Navy. 

Prepositioning  -  As  a  key  element  of  sea  basing,  afloat  prepositioning  provides  the  military  equipment  and 
supplies  for  a  contingency  forward  deployed  in  key  ocean  areas  before  it  is  needed.  The  MSC  Prepositioning 
Program  supports  the  U.S.  Army,  Navy,  Air  Force  and  Marine  Corps  and  the  Defense  Logistics  Agency. 
Prepositioning  ships  remain  at  sea,  ready  to  deploy,  on  short -notice,  the  vital  equipment,  fuel  and  supplies  to 
initially  support  our  military  forces  in  the  event  of  a  contingency. 

Sealift  -  The  mission  of  the  Sealift  Program  is  to  provide  ocean  transportation  to  the  Department  of  Defense  by 
meeting  its  sealift  requirements  in  peace,  contingency  and  war. 

There  are  significant  differences  in  the  requirements  invoked,  logistics  systems,  operator  training,  age  of  crew, 
and  crew  size  between  MSC  ships  and  USN  ships.  The  most  significant  difference  is  the  use  of  commercial 
requirements  such  as  ABS  Rules  including  Steel  Vessel  Rules  (SVR),  Fligh  Speed  Craft  (HSC)  Rules,  and  High 
Speed  Naval  Craft  (HSNC)  Guide.  The  use  of  commercial  requirements  means  that  organizations  such  as  ABS 
and  USCG  are  involved  in  the  review  and  certification  of  the  design.  It  is  MSC’s  prevailing  practice  that  new  T- 
SHIPS  are  ABS  classed  and  receive  a  USCG  Certificate  of  Inspection  (COI).  T-SHIPs  may  be  procured  to  a  mix 
of  military  and  commercial  requirements.  If  there  are  unique  military  missions  and  operations  performed  by  some 
of  these  vessels,  it  may  not  be  feasible  to  obtain  a  traditional  COI.  In  the  future,  an  “annotated  COI”  (annotated  to 
reflect  the  use  of  military  standards  in  select  instances)  may  be  an  available  alternative. 

New  T-SHIPs  are  generally  procured  for  the  MSC  via  a  PEO  Ships  acquisition  program  with  SEA  05  as  the 
Technical  Authority  for  the  acquisition.  Considering  all  the  differences  between  T-SHIPs  and  USN  ships,  it  is 
clear  that  the  extent  of  TWH  involvement  should  be  different  as  well. 

X.2  T-SHIP  REQUIREMENTS  DRIVERS. 

Requirements  Overview 

T-SHIP  specifications  generally  contain  a  mix  of  Military  (Military  Specification  [MILSPEC])  and  Commercial 
requirements  with  the  goal  of  being  as  commercial  as  practical  given  the  mission  of  the  ship. 
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MILSPECS  were  written  for  the  intended  purpose  of  providing  direction/rules/oversight  for  the  application  of 
approved  equipment/materials  and  components  to  USN  combatants  in  order  to  obtain  an  inherent  survivability 
and  retain  mission  capabilities  in  a  combat  environment.  MILSPECs  focus  on  end  use  survival  and  performance 
in  a  hostile  environment.  In  NAVSEA,  each  MILSPEC  is  owned  by  a  TWH  who  ensures  that  the  MILSPEC  is 
current  and  accurate.  MILSPECs  generally  address  equipment  and  component  end  items  and  materials  -  pumps, 
piping,  steel,  etc.  In  an  effort  to  make  ships  more  affordable  and  move  toward  open  standards,  many  MILSPECs 
have  been  replaced  with  commercial  standards.  In  some  cases  the  MILSPEC  became  the  industry  standard. 
MILSPECs  will  only  be  used  on  T-SHIPS  when  there  is  compelling  justification. 

ABS  Rules  and  USCG  Regulations  are  written  for  commercial  ship  applications  with  the  primary  emphasis  of 
safety  of  life  at  sea  and  the  ability  to  withstand/survive  the  effects  of  the  environment  and  errors  by  operating 
personnel.  The  principal  requirements  used  in  U.S.  commercial  ship  construction  are: 

USCG  regulations  or  the  applicable  codes  of  the  U.S.  Code  of  Federal  Regulation  (CFR).  All  U.S.  Flagged 
vessels  are  required  to  comply  with  these  regulations.  Government  owned  (“Public”)  vessels  are  exempt. 

SOLAS  -  Safety  of  Life  at  Sea  regulations:  International  safety  regulations  administered  by  the  International 
Maritime  Organization  (IMO).  Rules  are  voted  on  by  member  states.  USCG  is  the  state  authority  for  the  U.S.  on 
IMO  matters.  USCG  requires  compliance  with  SOLAS  regulations  for  a  vessel  certificated  for  International 
voyages,  over  500  GT,  and  all  Passenger  Vessels.  Public  vessels  are  exempt  from  SOLAS  although  the  Navy  has 
chosen  to  comply  with  SOLAS  for  many  of  the  vessels  operated  by  the  MSC. 

MARPOL  -  International  Convention  for  the  Prevention  of  Pollution  from  Ships:  The  MARPOL  Convention  is 
the  international  convention  covering  prevention  of  pollution  of  the  marine  environment  by  ships  from 
operational  or  accidental  causes.  The  Convention  includes  regulations  aimed  at  preventing  and  minimizing 
pollution  from  ships  -  both  accidental  pollution  and  that  from  routine  operations.  These  regulations  are 
administered  by  IMO.  The  regulations  are  incorporated  into  the  Code  of  Federal  Regulations  (CFRs),  and 
enforced  by  the  USCG  as  the  flag  state  authority  as  soon  as  they  are  ratified.  MARPOL  compliance  is  sought  in 
almost  all  cases.  Public  vessels  are  exempt  from  MARPOL,  but  there  are  ramifications  of  invoking  the  public 
vessel  exemption  that  may  not  be  in  the  Navy’s  best  interest  (ex:  foreign  port  access  may  be  denied). 

ABS  Rules  -  ABS  is  a  not-for-profit  corporation  that  promotes  safety  and  environmental  protection  for  the 
marine  industry.  This  is  achieved  through  the  establishment  and  application  of  technical  standards,  known  as 
Rules,  for  the  design,  construction,  and  operational  maintenance  of  ships  and  other  marine  structures. 
Classification  is  a  process  that  certifies  adherence  to  these  Rules.  ABS  standards  are  jointly  accepted  “consensus” 
standards  developed  by  industry  and  vessel  owners/operators  to  meet  affordability,  reliability,  function,  and  safety 
criteria.  ABS  is  a  member  of  the  International  Association  of  Classification  Societies  (IACS)  and  many  of  the 
rules  are  common  with  other  classification  societies. 

Owner’s  Requirements  -  These  are  requirements  not  covered  in  the  above  mentioned  regulations  that  include 
the  vessels  mission  requirements  and  any  performance  enhancements  desired  by  the  owner.  Owner’s 
requirements  may  include  additional  commercial  standards  such  as  American  Society  of  Testing  Materials 
(ASTM). 

T-SHIP  specifications  invoke  some  military  standards  in  areas  where  no  commercial  equivalent  exists  such  as 
underway  replenishment,  ordnance  handling  at  sea,  and  shock.  ABS  standards  are  occasionally  (but  rarely)  more 
stringent  than  MILSPEC  standards  and  can  often  conflict  with  a  military  requirement.  When  conflicts  occur, 
exemptions,  waivers,  equivalences,  or  some  other  form  of  approval  is  generally  required  from  USCG  in  order  to 
deviate  from  the  commercial  requirement  and  still  maintain  commercial  certification. 

Commercial  requirements  are  frequently  used  even  in  cases  where  military  standards  do  exist.  T -SHIP 
requirements  typically  include  commercial  standards  that  differ  from  accepted  Navy  standards  in  areas  such  as 
accommodation,  manning,  and  damage  control. 
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X.3  PROGRAM  INITIATION  THROUGH  RFP  RELEASE. 

The  SDM  is  the  sole  accountable  Technical  Authority  for  Auxiliary  and  Special  Mission  Ships  and  is  the  direct 
interface  between  the  Program  Office  and  the  NAVSEA  technical  community. 

One  of  the  first  actions  for  the  SDM  is  to  identify  potential  “fenced  areas”  for  the  program.  “Fenced  areas”  are 
typically  Military  Unique,  Fligher  Technical  Risk,  and  Customer  Critical  areas.  The  SDM  will  then  need  to  make 
an  initial  determination  of  which  TWHs  will  be  asked  to  fully  participate  in  the  ship  design  efforts. 

The  following  steps  for  determining  TWH  involvement  in  T-SHIP  efforts  will  be  followed: 

•  SDM  will  conduct  a  TWH  Engagement  Planning  (TWHEP)  Meeting. 

•  The  SDM  will  brief  ALL  TWHs,  ABS,  and  other  SYSCOMs  on  the  new  ship  program,  including 
identification  of  proposed  “fenced  areas.” 

•  TWHs/ABS/Other  SYSCOMs  provide  input  to  SDM  on  “fenced  areas”  for  Navy  certification. 

•  SDM,  in  consultation  with  TWHs,  finalizes  “fenced  areas”  such  as: 

-  Military  Unique  (e.g.,  UNREP,  C4I,  Aviation,  Ordnance  Safety  to  deal  with  combat  ready  vehicles 
—  areas  with  no  applicable  commercial  std) 

-  Higher  Technical  Risk  (e.g.,  high  speed  catamaran  hull  form) 

-  Customer  Critical  (e.g.,  clean  power  requirements,  speed  for  the  Army  LMSRs) 

•  SDM  receives  concurrence  on  proposed  “fenced  areas”  from  the  CSE  Ships  and  documents  those  in 
serialized  correspondence. 

•  Only  TWHs  for  “fenced  areas”  will  be  required  to  participate  in  the  Ship  Specification  development. 
Only  TWHs  for  “fenced  areas”  will  be  required  to  certify  their  portions  of  the  Ship  Specification  using 
Attachment  2  (sample  Ship  Specification  “sign  off’  form.) 

•  SDM  will  be  focal  point  for  discussion  of  these  issues  with  the  Program  Manager. 

•  The  AEA  with  the  Program  Manager  will  include  funding  requirements  for  “fenced  areas.” 

•  If  there  are  “fenced  area”  issues  internal  to  SEA  05,  they  shall  be  adjudicated  prior  to  Ship 
Specification  release  by  CSE  Ships,  or  SEA  05  if  necessary. 

•  Other  TWHs  may  be  invited  to  provide  comments  during  Ship  Specification  development. 

•  SDM  will  negotiate  funding  requests  for  TWHs  consultation  services  and  include  them  in  the  AEA 
(Note:  funding  may  not  be  available). 

•  SDM  will  be  the  technical  adjudication  authority  for  any  comments  resulting  from  TWH  consultation 
services. 

•  Non  fenced  area  TWHs  will  not  be  required  to  certify  the  Ship  Specification,  and  will  not  be 
accountable. 

The  top  level  contractual  technical  requirements  are  contained  in  the  Ship  Specification.  The  Ship  Specification 
is  developed  by  SEA  05  under  the  direction  of  the  SDM.  The  Ship  Specification  is  signed  by  CSE  Ships  and  the 
Program  Manager  prior  to  release  of  the  RFP. 

The  SDM  must  ensure  that  the  Ship  Specification,  DRL,  and  Contract  SOW  are  well  integrated.  The  validation 
requirements  must  match  the  DRL  and  SOW  in  terms  of  the  standards  to  be  used  for  validation  of  the  requirement 
and  who  will  be  the  certifying  authority. 


X-4 


S9800-AC-MAN-01 0 


For  T-SHIPs  that  have  more  extensive  military  missions,  it  may  be  impossible  to  obtain  a  traditional  COI  because 
of  numerous  and  significant  conflicts  between  commercial  regulations  and  the  ship’s  military  mission 
requirements.  USCG  and  SOLAS  regulations  allow  alternatives  to  be  proposed.  However,  these  alternatives 
must  be  proven  to  have  an  equivalent  level  of  safety  to  that  required  by  the  regulations.  It  will  likely  be 
impossible  to  achieve  a  level  of  safety  equivalent  to  that  of  a  commercial  ship  that  does  not  perform  the  military 
mission.  For  these  cases,  the  ship  will  meet  CFR  and  SOLAS  regulations  as  much  as  practical.  In  areas  where  a 
commercial  level  of  safety  cannot  be  achieved,  the  SDM,  in  conjunction  with  the  appropriate  TWH(s),  may  (if 
approved  by  the  appropriate  authority)  act  as  the  Flag  State  Authority  and  approve  the  deviation  from  commercial 
requirements.  Such  actions  must  be  coordinated  with  ABS  to  ensure  that  actions  contemplated  do  not  negatively 
impact  the  ability  of  the  ship  to  receive  a  classification  certificate.  The  SDM  will  use  the  appropriate  authority 
(such  as  WSESRB  for  weapons  handling)  to  ensure  safety  of  operations. 

A  Ship  Certification  Matrix  (SCM)  shall  be  developed  by  the  SDM  in  conjunction  with  the  Ship  Specification. 
The  purpose  of  the  SCM  is  to: 

•  Map  certification  requirements  to  documentation 

•  Minimize  duplication  of  inspections 

•  Identify  of  the  types  of  certification  required 

•  Identify  the  certification  agent(s) 

The  SCM  identifies  the  organization  that  will  be  the  primary  POC  for  coordinating  and  overseeing  certification 
efforts  for  a  particular  area.  However,  in  order  to  satisfy  all  specified  requirements,  some  systems  may  require 
certification  and  verification  actions  by  more  than  one  agency.  In  these  cases,  the  primary  POC  will  coordinate 
oversight.  The  SCM  should  be  included  with  the  RFP  as  guidance  to  be  used  by  the  Shipbuilder  in  development 
of  their  ship  certification  plan. 

X.4  PRELIMINARY/CONTRACT  DESIGN  PHASE. 

SDM  interface  with  the  Shipbuilder(s)  during  this  phase  will  be  determined  by  the  Program  Office  and 
Contracting  Officer.  The  involvement  may  be  limited  prior  to  DD&C  contract  award  for  competitive  reasons. 
Typically,  information  can  be  provided  to  Shipbuilders  as  long  as  the  same  information  is  made  available  to  all 
potential  Shipbuilders  in  a  timely  manner.  The  Program  Office  and  SDM  will  work  jointly  to  determine  the  best 
method  for  providing  the  appropriate  level  of  comments  to  be  passed  to  the  Shipbuilders  during  this  phase. 

At  the  completion  of  Preliminary  Design  and  Contract  Design,  the  SDM  will  conduct  SETRs  and/or  Design 
Maturity  Assessments  (DMAs)  to  review  the  status  and  maturity  of  the  design(s)  with  CSE  Ships  and  appropriate 
TWHs.  This  assessment  will  review  the  current  status  of  the  design  in  accordance  with  design  review  criteria 
established  in  the  Ship  Design  Managers  Manual.  The  recommendations  will  be  provided  to  the  Program 
Manager.  Typically  some  areas  of  non-compliance  will  be  identified.  In  those  cases,  the  requirement  may  be 
reemphasized  and  enforced,  or  a  relaxation/change  may  be  proposed  if  technically  appropriate. 

Shipbuilders  typically  develop  a  Shipbuilding  Specification  in  response  to  an  RFP  for  DD&C.  A  technical  review 
panel  is  formed  using  experts  from  SEA  05,  ABS,  NSWC,  MSC,  NAVAIR,  SPAWAR,  and  support  contractors  to 
review  and  comment  on  the  Shipbuilder  technical  proposals,  including  the  Shipbuilding  Specification.  The 
Shipbuilding  Specification  becomes  part  of  the  contract  upon  award  of  the  DD&C  contract.  The  Ship 
Specification  (developed  to  support  the  RFP)  remains  part  of  the  contract  and  is  a  higher  order  precedence  than 
the  Shipbuilding  Specification.  The  Shipbuilding  Specification  shall  be  approved  by  CSE  Ships  and  the  Program 
Manager.  For  programmatic  reasons,  it  will  be  difficult  to  obtain  approval  prior  to  contract  award.  However,  the 
SDM  will  coordinate  approval  of  “fenced  areas”  as  soon  as  possible.  An  approved  Shipbuilding  Specification 
shall  be  one  of  the  entrance  criteria  for  the  Critical  Design  Review  which  will  occur  during  Detail  Design. 
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All  changes  to  the  Ship  Specification  or  the  Shipbuilding  Specification  are  approved  by  the  SDM  before 
forwarding  to  the  Program  Office  for  implementation.  The  SDM  also  provides  technical  interpretations  of  Ship 
Specification  requirements. 

X.5  SHIP  DETAIL  DESIGN  AND  CONSTRUCTION  PHASE. 

Communications  with  the  Shipbuilder  after  DD&C  award  are  less  constrained,  but  must  still  be  well  documented. 
The  SDM  will  typically  be  allowed  direct  contact  with  Shipbuilder  counterparts  to  provide  requirements 
interpretations  and  help  resolve  issues.  The  SDM  will  be  the  technical  lead  for  the  review  of  any  proposed 
changes  to  the  System  or  Shipbuilding  Specification.  The  SDM  will  be  the  lead  for  all  DD&C  design  reviews. 

During  DD&C  the  Shipbuilder  will  produce  data  deliverables  that  the  government  will  review  for  compliance 
with  contract  requirements.  Data  items  will  also  be  submitted  by  the  Shipbuilder  to  ABS  for  review  and  approval, 
as  appropriate. 

A  PRR  shall  be  completed  prior  to  allowing  the  Shipbuilder  to  begin  construction  of  the  vessel.  The  SDM  shall 
be  a  key  participant  in  the  technical  assessment  conducted  during  the  PRR.  The  Shipbuilder  should  specifically 
address,  and  the  SDM  will  focus  on,  the  maturity  of  the  ship  design  and  the  degree  of  completion  of  the  detailed 
design  drawings  along  with  the  maturity  level  of  research  and  development  efforts  of  any  new  technologies  that 
will  be  used. 
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X.6  ROLES  AND  RESPONSIBILITIES. 

X.6.1  Ship  Design  Manager.  SDM  responsibilities  are  covered  in  NAVSEA  technical  authority  instructions 
and  Section  3  of  this  manual.  The  following  items  have  been  excerpted  as  particularly  relevant  to  SDMs  assigned 
to  T-SHIP  Programs:  Make  integration  decisions  and  ensure  interoperability 

•  Support  programmatic  authorities  and  MSC  by  providing  best  value  engineering  and  technical  products 

•  Identify  and  evaluate  technical  alternatives,  determine  which  are  technically  acceptable,  and  perform 
associated  risk  and  value  assessments 

•  Ensure  technical  products  are  in  conformance  with  technical  policy,  standards,  processes,  and 
requirements  (Where  they  are  not,  identify  options  and  associated  risks  and,  if  appropriate,  approve 
non-conformances  or  engineering  changes  in  a  manner  that  ensures  risks  are  technically  acceptable.) 

•  For  operational  systems  that  do  not  meet  technical  requirements,  assess  and  recommend  options  and 
identify  associated  risks 

•  Provide  leadership  and  be  accountable  for  all  engineering  and  technical  decision-making  including 
coordination  with  other  government  activities,  such  as  NAVAIR  and  SPAWAR 

•  Promote  and  facilitate  communications  throughout  the  technical  community  to  ensure  appropriate 
individuals  and  organizations  are  aware  of  and  involved  in  technical  issues  and  technical  decisions,  and 
that  all  applicable  technical  requirements  are  identified  and  understood  (For  T-SHIP  programs  this  will 
include  ABS  and  USCG  in  addition  to  other  Navy  organizations  like  NAVAIR  and  SPAWAR.) 

•  Develop  cost  forms  for  SEA  05C  use  in  establishing  the  vessel’s  cost 

•  Ensure  lessons  learned  and  best  practices  are  strongly  considered  for  implementation 

•  Apprise  the  Deputy  Warranting  Officer  of  significant  engineering  and  technical  authority  issues, 
including  technical  disagreements  that  cannot  be  resolved  with  programmatic  authorities 

•  Identify  technical  risk  and  provide  mitigating  strategies  for  reducing  the  risk  to  acceptable  levels 

•  Report  the  status  of  certification  via  a  serialized  memo  to  SEA  05D.  These  reports  will  be  provided 
once  at  30  days  prior  to  the  Production  Readiness  Review,  and  then  again  monthly  starting  6  months 
prior  to  Builder’s  Trials  (BT)  and  continuing  until  BT  is  complete 

The  SDM  has  the  responsibility  to  translate  the  CDD  into  Ship  Specification  language  and  to  work  with  ABS  and 
MSC  to  ensure  the  appropriate  commercial  requirements  are  integrated  into  the  design  and  eliminate  conflicts 
between  commercial  and  military  requirements.  To  the  extent  the  SDM  can  influence  CDD  development;  the 
document  should  clearly  delineate  the  extent  of  military  design  features  desired.  The  clearer  the  CDD  is  with 
respect  to  commercial  and  military  areas,  the  easier  it  will  be  develop  the  Ship  Specification. 

The  SDM  is  the  Technical  Authority  for  the  entire  ship.  While  outside  organizations  such  as  ABS  may  be  listed 
as  the  certifying  authority  for  particular  areas  of  the  ship,  the  SDM  must  ensure  the  certification  provided  by  those 
organizations  meets  the  ship’s  top  level  requirements  or  CDD.  If  the  SDM  disagrees  with  an  approval  or 
approach  taken  by  an  outside  certification  authority  the  disagreement  should  be  presented  to  the  Program 
Manager  with  a  proposal  to  correct  the  situation.  If  the  contract  only  requires  certification  from  ABS,  and  not 
Navy  approval,  a  technically  justified  change  from  the  regulatory  body  approved  solution  may  require  a  contract 
modification  to  implement. 
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The  SDM  ensures  that  technical  recommendations  are  based  on  sound  engineering  vice  schedule  and  cost  related 
drivers.  While  the  SDM  must  be  fully  supportive  of  the  cost  and  schedule  constraints  of  the  Program  Manager, 
technical  recommendations  are  focused  on  technical  performance,  operational  readiness,  and  safety.  The  SDM 
should  propose  a  range  of  cost-effective,  technically  acceptable  solutions  to  the  Program  Manager,  and  while 
recommending  a  preferred  technical  solution,  be  willing  to  accept  any  technically  acceptable  solution  that  does 
not  compromise  operational  readiness,  safety,  or  the  top  level  technical  performance  requirements.  If  the  Program 
Manager  selects  a  path  that  is  not  technically  acceptable,  the  SDM  must  raise  the  issue  to  SEA  05D  and  SEA  05. 

Other  more  typical  SDM  responsibilities,  such  as  technical  team  budgets  and  document  development,  are  covered 
in  the  relevant  sections  of  the  manual. 

X.6.2  SEA  05  Technical  Authorities.  The  SDM  is  the  sole  technical  interface  with  the  Program  Manager.  As 
T-SHIPs  are  built  largely  to  commercial  regulations,  accountable  TWH  interface  is  limited  to  “fenced  areas”  as 
discussed  above.  SDMs  interface  with  other  TWHs  to  ensure  consistency  in  selection,  interpretation,  and 
implementation  of  technical  requirements  and  policies.  TWH  input  may  be  sought  when  there  is  an  issue  with 
meeting  a  military  (non  ABS)  requirement  or  a  requirement  interpretation  is  needed.  TWHs  are  not  generally 
involved  with  the  day  to  day  review  of  the  design.  The  SDM’s  technical  team,  SUPSHIP,  and  MSC  (and  TWHs 
as  needed)  perform  the  function  of  monitoring  compliance  with  the  specifications.  X.6.3  American  Bureau  of 
Shipping.  The  SDM  should  arrange  meetings  with  ABS  early  on  in  the  Program  to  ensure  an  understanding  of 
the  technical  requirements,  expectations  relative  to  operational  environments  and  special  features  of  the  design. 

Program  Initiation  through  RFP  Release  &  Preliminary/Contraet  Design  Phase  -  The  SDM  will  use  the 
support  of  the  ABS  Government  Operations  Office  to  provide  interpretations  of  commercial  regulations  and  to 
assist  in  resolution  of  conflicts  between  commercial  and  military  requirements.  The  ABS  Government  Operations 
Office  will  be  an  active  participant  in  the  SDM’s  technical  team  throughout  the  acquisition.  The  SDM  will 
coordinate  funding  for  the  ABS  Government  Operations  Office  for  direct  support  to  the  SDM.  This  support 
includes: 


•  Participation  in  the  development  of  the  Ship  Specification  and  ship  certification  matrix 

•  Input  on  the  various  Class  notations  for  applicability  and  resulting  impacts  to  the  program 

•  Interpretation  of  ABS,  SOLAS,  USCG,  and  MARPOL  regulations 

•  Notification  of  new  regulations  that  may  impact  the  program 

•  Interface  with  USCG  when  required 
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Ship  DD&C  Phase  -  The  ABS  role  in  this  phase  is  to  review  the  design  and  ensure  it  is  in  compliance  with 
applicable  ABS  Rules  and  other  Class  Notations  invoked  in  the  contract.  If  invoked,  ABS  will  review  the  design 
for  compliance  with  SOLAS  and  MARPOL  requirements.  After  contract  award,  the  SDM  will  not  correspond 
directly  with  ABS  Americas  (Houston).  The  ABS  Government  Operations  Office  can  contact  ABS  Americas 
(Houston)  on  behalf  of  the  SDM  to  obtain  information.  ABS  Americas  (Houston)  is  usually  contracted  by  the 
Shipbuilder  and  correspondence  is  between  the  Shipbuilder  and  ABS  with  copies  provided  to  the  government  for 
information.  ABS  will  provide  copies  of  all  correspondence  they  generate  directly  to  the  government.  E-mail  and 
telecon  records  are  also  considered  correspondence  and  must  be  furnished  to  the  government.  Timely  distribution 
of  correspondence  is  essential.  This  requirement  should  be  in  the  contract  statement  of  work.  A  sample  DRL  is 
provided  as  attachment  (3).  The  SDM  will  rely  heavily  on  the  Program  Office  being  proactive  and  vigilant  in 
enforcing  the  contract  requirements  for  correspondence. 

The  local  Shipbuilder  ABS  representative  and  appropriate  representatives  from  ABS  Americas  (Houston)  should 
be  invited  to  all  design  reviews.  ABS  should  have  a  specific  design  review  agenda  item  and  an  unconstrained 
speaking  role  to  discuss  overall  classification  status  and  classification  issues.  The  Shipbuilder  should  have  no 
authority  to  alter  the  information  presented  by  ABS.  ABS  should  be  an  active  participant  in  any  Working  Groups 
established  to  resolve  regulatory  issues. 

X.6.4  USCG.  USCG  issues  the  COI  for  US  Flagged  Vessels  for  compliance  with  applicable  requirements  in  the 
Code  of  Federal  Regulations.  However,  it  may  be  impossible  to  obtain  a  traditional  COI  for  some  T-SHIPs 
because  of  the  numerous  and  significant  conflicts  between  commercial  regulations  and  the  ship’s  military  mission 
requirements.  The  USCG  Marine  Safety  Center  performs  plan  review  on  key  drawings  and  calculations, 
depending  on  whether  the  vessel  is  in  the  Alternative  Compliance  Program  (ACP)  or  not.  Under  ACP,  a  vessel  is 
reviewed  and  inspected  by  ABS  acting  on  behalf  of  USCG.  ABS  makes  a  recommendation  to  USCG  that  they 
issue  a  COI.  Although  ABS  performs  the  plan  review,  issues  involving  interpretation  or  equivalence 
determinations  of  SOLAS  and  MARPOL  regulations  must  go  to  the  USCG  for  final  determination.  ABS  may 
provide  the  interface  with  USCG  on  these  matters.  As  the  U.S.  representative  to  the  1MO,  USCG  is  the 
designated  Flag  State  Authority  for  implementation  of  international  safety  and  pollution  standards. 

Program  Initiation  through  RFP  Release  &  Preliminary/Contraet  Design  Phase  -  The  SDM  should  have 
early  contact  with  USCG  Marine  Safety  Center  to  provide  them  with  an  understanding  of  the  ship  and  receive 
feedback  on  potential  hard  spots  with  regulatory  compliance.  While  it  may  be  somewhat  useful  to  try  and  gain 
upfront  concurrence  on  a  particular  aspect  of  the  design,  USCG  Marine  Safety  Center  is  a  detail  plan  review 
organization  and  final  concurrence  may  not  be  achievable  until  the  design  details  are  completed. 

Ship  DD&C  Phase  -  After  DD&C  award,  the  Shipbuilder  interfaces  with  USCG  to  obtain  plan  approval  for 
those  items  requiring  USCG  review.  If  the  Program  is  enrolled  in  ACP,  then  ABS  performs  the  plan  review  on 
behalf  of  USCG.  ABS  interfaces  with  USCG  on  matters  of  interpretation  and  equivalent  level  of  safety 
determinations. 
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X.6.5  Other  Government  Activities  (NAVAIR,  SPAWAR,  Marines,  Army,  etc.).  The  SDM  will  require 
extensive  contact  and  interactions  with  engineering  counterparts  at  other  government  activities  (OGAs), 
especially  in  support  of  the  standard  Net  Ready  KPP  required  by  ship  CDDs,  and  any  ship  required  to  interface 
with  aviation  assets.  Formal  teaming  arrangements  should  be  established  early  in  the  acquisition  process,  with  the 
goal  of  creating  a  multi-functional  Design  Team,  led  by  the  SDM  with  dedicated  representatives  assigned  by 
OGAs.  It  is  recommended  that  key  OGA  reps  be  collocated  with  the  SDM,  at  least  part  time,  when  there  is  a 
requirement  for  significant  interface.  OGAs  will  be  responsible  for  identifying  system  requirements,  coordinating 
acquisition  of  GFE,  and  providing  ship  interface  control  documents  necessary  to  support  their  equipment.  The 
SDM,  assisted  by  the  OGAs,  must  determine  the  interface  and  certification  requirements  and  documents  the 
process  in  an  attachment  to  the  construction  contract  as  early  as  possible.  Additionally,  roles  and  responsibilities 
will  need  to  be  worked  out  and  formalized  in  Memorandums  of  Agreements.  After  interface  and  certification 
requirements  are  pinned  down,  the  SDM  will  continue  to  work  with  select  OGAs  to  resolve  outstanding  design, 
construction  and  support  issues. 

X.6.6  Military  Sealift  Command.  MSC  is  the  operator  and  maintainer  of  T-SHIPs  after  they  are  delivered.  As 
such,  they  are  an  important  customer  of  the  SDM.  MSC  should  be  integrated  into  the  SDM’s  technical  team  to 
review  and  comment  on  all  technical  products.  This  includes  early  products  such  as  the  Ship  Specification  and 
other  deliverables  throughout  the  design  and  construction  process.  MSC  can  provide  a  commercial  operator 
perspective  that  is  not  typically  available  within  the  NAVSEA  community.  It  is  recommended  that  each  T-SHIP 
program  have  a  full  time  onsite  MSC  representative  who  is  integrated  into  the  SDM’s  technical  team  for  review 
of  technical  products  both  before  and  after  DD&C  award.  They  should  also  be  part  of  the  proposal  evaluation 
team. 

During  DD&C,  MSC  will  typically  provide  one  or  more  Owner’s  Representatives  (MSC-OR)  on  site  at  the 
Shipbuilder.  If  MSC-ORs  are  onsite  they  may  be  integrated  into  the  SDM’s  technical  team  in  the  same  way 
SUPSHIP  engineers  are  integrated,  to  provide  technical  review  of  data  items,  onsite  review  of  construction  issues 
and  onsite  interface  with  Shipbuilder  engineers. 

X.6.7  Shipbuilder.  The  Shipbuilder  should  be  involved  in  the  program  as  early  as  possible.  The  Shipbuilder’s 
DD&C  experience  will  be  valuable  during  early  stages  to  the  extent  allowed  by  the  acquisition  strategy  and  the 
need  to  maintain  competition/protect  proprietary  information. 

For  T-SHIP  programs,  the  Shipbuilder,  or  their  design  agent,  develops  the  Shipbuilding  Specification.  The 
Shipbuilding  Specification  provides  greater  detail  and  the  “how”  in  response  to  the  Ship  Specification.  The 
Shipbuilding  Specification  should  be  developed  prior  to,  and  be  the  primary  technical  basis  for,  DD&C  award. 

The  more  review  and  comment  iterations  of  the  Shipbuilding  Specification  that  can  occur  between  the  SDM’s 
technical  team  and  Shipbuilder,  the  better  the  specification  will  be,  reducing  the  risk  of  expensive  changes  in  the 
future. 

Communication  during  and  after  design  reviews  that  are  held  prior  to  DD&C  award  may  be  constrained  due  to 
competition.  A  government  only  meeting  should  be  held  just  after  each  design  review  to  agree  on  comments  to 
be  provided  to  the  Shipbuilder.  These  comments  are  then  provided  verbally  to  the  Shipbuilder  right  after  the 
government  only  meeting  and  then  provided  in  writing  via  letter  from  the  contracting  officer.  Typical  comments 
include  items  where  it  appeared  the  contract  was  not  being  met  as  well  as  pointing  out  notable  strengths  and 
weaknesses  in  the  Shipbuilder’s  design.  Suggestions  for  possible  solutions  are  not  provided  if  in  a  competitive 
phase. 

The  shipbuilding  contract  shall  include  a  requirement  that  the  Shipbuilder  concurrently  provide  to  the  government 
one  copy  of  all  submittals  sent  to  ABS.  The  clause  shall  also  require  ABS  to  provide  copies  of  all  correspondence 
they  generate  directly  to  the  government.  These  requirements  and  specific  timelines  will  be  spelled  out  in  the 
appropriate  DRL.  (see  attachment  3  for  a  sample  DRL.) 
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X.6.8  Supervisor  Of  Shipbuilding.  SUPSHIP  may  play  a  vital  role  in  monitoring  the  design  and  construction  of 
the  ship  after  DD&C  contract  award.  The  SUPSHIP  staff  may  be  integrated  into  the  SDM’s  technical  team  to 
support  review  and  comment  of  Shipbuilder  technical  data  items  particularly  for  a  lead  ship.  An  IDE  will  help 
provide  seamless  integration  for  SIJPSHIP  and  SDM’s  technical  team  reviews.  SUPSHIP  can  also  interface 
directly  with  Shipbuilder  design  engineers  to  help  resolve  issues  and  make  sure  government  concerns  are 
understood.  The  SDM  can  request  SUPSHIP  assistance  to  resolve  issues  that  may  require  onsite  interface  with 
the  Shipbuilder  or  hands  on  review  of  an  item  already  under  construction.  SUPSHIP  personnel  will  also  request 
the  SDM’s  assistance  in  determining  whether  or  not  a  particular  design  solution  being  pursued  by  the  Shipbuilder 
meets  the  intent  of  the  specifications. 

X.7  RESOLUTION  OF  TECHNICAL  ISSUES. 

X.7.1  Conflicts  in  Requirements  (Regulatory  and  Navy).  In  cases  where  hybrid  (mix  of  commercial  and 
military)  certification  requirements  exist,  a  Tactical  Problem  Solving  Working  Group  composed  of  USCG,  ABS, 
Shipbuilder,  MSC,  NAVSEA,  SUPSHIP,  and  Program  Office  representatives  should  be  required  in  the  contract 
statement  of  work..  Sample  statement  of  work  wording  is  provided  in  attachment  (4).  This  group  should  meet  as 
needed  to  resolve  issues  and  conflicts  between  commercial  and  military  requirements.  This  group  can 
substantially  shorten  the  resolution  process  and  make  sure  all  organizations  are  in  sync  with  the  proposal  put 
forward.  The  Working  Group  will  evaluate  the  factors  associated  with  regulatory  requirements  for  the  program  in 
a  disciplined  and  structured  manner  and  will  share  information  and  solutions. 

X.7. 2  Other  Technical  Issues,  Design  Problems.  Technical  issues  that  are  not  regulatory  in  nature  shall  be 
handled  between  the  SDM  and  the  Shipbuilder,  using  established  procedures.  In  cases  where  the  Shipbuilder  is 
seeking  relief  from  a  particular  Ship  Specification  requirement,  the  SDM  will  carefully  review  each  issue, 
consulting  with  the  TWH  as  appropriate.  The  final  resolution  should  be  coordinated  with  the  Program  Office  and 
an  ECP,  RFW  or  RFD  should  be  processed,  if  needed. 

X.7. 3  Documentation  of  Technical  Decisions.  Significant  technical  decisions  will  be  documented  using  an 
agreed  upon  DDM  approach,  and/or  official,  serialized  memorandums  as  appropriate. 

X.8  SUMMARY. 

Auxiliary  &  Special  Mission  ships  (commonly  referred  to  a  “T-SHIPS”)  are  generally  procured  for  the  MSC  via  a 
PEO  Ships  acquisition  Program.  In  accordance  with  the  basic  tenets  of  the  NAVSEA  Competency  Aligned 
Organization,  SEA  05  (the  R&SE  Competency)  provides  all  required  engineering  and  technical  support  to  the 
NAVSEA  affiliated  PEOs.  SDMs  are  the  single  point  of  contact  with  Program  Offices  for  providing  this 
engineering  and  technical  support.  This  document  provides  process  guidance  and  defines  roles  and 
responsibilities  for  interactions  between  the  Program  Office  and  the  SDM  through  all  phases  of  T -SHIP 
acquisition.  It  is  not  intended  to  be  a  narrowly  prescriptive  document  but  to  provide  a  guide  based  on  proven  past 
practice  and  typical  T-SHIP  acquisition  strategies.  The  goal  is  to  have  more  consistent  processes  in  order  to  better 
plan  and  execute  the  design  management  of  T-Ship  programs. 
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T-SHIP  CONOPS  Attachment  1 

SEA  05  Policy  for  Executing  Technical  Authority  on  Auxiliary  and  Special  Mission  Ship  Designs 


DEPARTMENT  OF  THE  NAVY 

NAVAL  SEA  SYSTEMS  COMMAND 
1333  ISAAC  HULL  AVE  SE 

WASHINGTON  NAVY  YARD  DC  20376-0001  IN  REPLY  TO 

54  00 

Ser  05D/183 

01  May  08 

MEMORANDUM 

From:  SEA  05 

To:  SEA  05  Group  Heads  and  Division  Directors 

Sub j  :  EXECUTING  TECHNICAL,  AUTHORITY  ON  AUXILIARY  AND  SPECIAL 

MISSION  SHIPS 

1.  Effective  immediately,  the  SEA  05  policy  concerning  the 

execution  of  technical  authority  for  auxiliary  and  special 
mission  ship  designs  is  as  follows: 

•  The  SEA  05D  Ship  Design  Manager  (SDM)  is  the  sole 
accountable  Technical  Warrant  Holder  ( TWH ) . 

•  Only  the  SDM  and  Chief  Systems  Engineer  (CSE)  SHIPS  will 
certify  and  sign  the  specifications. 

•  The  SDM  will  identify  "fenced  areas”  of  the  specifications 

(if  any)  such  as  pure  military  requirements  (ex:  UNREP, 

C4I,  ATFP ) ,  higher  technical  risk  areas  (ex:  firefighting 
to  deal  with  combat  ready  vehicles) ,  and  customer  critical 

areas  (ex:  Army  requirement  for  speed  on  LMSRs) - 

•  Fenced  areas  will  be  documented  in  a  memo  from  the  CSE 

Ships  to  the  Deputy  Warranting  Officers  and  leadership 

within  the  R&SE  competency. 

•  The  SDM  must  engage  appropriate  TWHs  for  fenced  areas 

•  The  SDM  may  consult  TWHs  for  other  areas  on  an  "advice 

only”  basis . 

2.  Background/ Jus t i f icat ion :  Auxiliary  and  Special  Mission 

ships  designs  are  inherently  lower  risk  and  represent  the  "third 
tier”  of  technical  complexity  in  the  R&SE  portfolio  (1st  tier  = 
nuclear  powered  ships,  2nd  tier  —  USN  combatants) .  To  a  large 
extent,  the  requirements  are  already  ”pre— engineered ”  (ex:  ABS 
Steel  Vessel  Rules,  CFR ,  SOLAS,  IMO,  IEEE,  ASME ,  etc) .  The 
American  Bureau  of  Shipping  certifies  ~80%+  of  the  ship  in 
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Subj  :  EXECUTING  TECHNICAL  AUTHORITY  ON  AUXILIARY  AND  SPECIAL 

MISSION  SHIPS 

support  of  the  "Classing"  process.  Using  the  S  DM  as  the  sole 
accountable  TWH  is  an  effective,  efficient,  and  risk  appropriate 
use  of  SEA  05  resources. 


3.  Intent:  TWHs  are  not  Joeing  excluded.  There  will  Joe 

technical  risks  and  technical  challenges  that  need  to  be 
addressed.  The  SDM  is  accountable  for  engaging  the  appropriate 
TWHs  for  help  making  the  "hard  calls’*. 


4.  Action:  SEA 

for  incorporation 
Manual  (which  is 
Design  Manager's 


OSD  will  develop  a  process  description  suitable 
into  the  Technical  Authority  Reguirements 
under  development^,  anc^  the  fisting  Ship 
Manual  . 


Navy 


K.  - 

Rear  Admiral, 
Chief  Engineer  I 
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T-SHIP  CONOPS  Attachment  2 
Review  and  Release  of  Ship  Specification  “Fenced  Areas” 

From:  TWH  for  fenced  area:  _ 

To:  SDM  for _ 

SUBJ:  REVIEW  AND  RELEASE  OF  SYSTEM  SPECIFICATION  “FENCED  AREAS” 

1 .  I  have  reviewed  “fenced  area”  portions  of  the  Ship  Specification  and  associated  references  that  are 
applicable  to  my  technical  warranted  area,  and  I  make  the  following  certification:  (check  one) 


a.  CERTIFY  W/O  RESERVATIONS 

I  certify  that  the  Ship  Specification  and  associated  references  for  my  warranted  area  meet  the  intent  of  the 
Program’s  Capability  Development  Document  (CDD),  and  concur  with  the  release  of  the  specification. 

b.  CERTIFY  CONTINGENT  ON  RESOLVING  RESERVATIONS. 

I  certify  that  the  Ship  Specification  and  associated  references  for  my  warranted  area  meet  the  intent  of  the 
Program’s  Capability  Development  Document  (CDD),  and  concur  with  the  release  of  the  specification 
with  the  reservations  noted  in  the  accompanying  write  up. 

c.  DO  NOT  CONCUR  WITH  RELEASE. 


I  do  not  concur  with  the  release  of  the  specification  for  reasons  as  noted  in  the  accompanying  write  up. 


Signature 

Code 

Date 

Warranted  Technical  Authority 

CT A/Group  Head 
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T-SH1P  COMOPS  Attachment  3 

Sample  Data  Requirements  List  for  Regulatory  Body  Correspondence 

PHASE  11  DATA  REQUIREMENTS 

CONTRACT  NO.:  N00024-07-R-2219  CLIN:  0006  CONTRACTOR: 

BLOCK  1  -  DATA  ITEM  No.:  DI-B080 


BLOCK  2  -  DATA  ITEM  TITLE:  REGULATORY  BODY  COMMUNICATIONS 


BLOCK  3  -  REFERENCE:  SOW  C  4.2.4.20  xxx 


BLOCK  4  -  DD  FORM  250  REQ:  LT 

BLOCK  5  -  DATA  DESCRIPTION 


1 .  Provide  copies  of  all  incoming  and  outgoing  communications  on  technical  matters,  including 
attachments/enclosures,  between  the  contractor  and  Regulatory  Bodies  and  Subcontractors  and  the  Regulatory 
Bodies  in  accordance  with  the  Contract.  Where  possible,  all  copies  shall  be  provided  in  electronic  format. 

2.  Communications  include  letters,  faxes,  memos,  electronic  mail,  and  memos  of  phone  conversations. 
Attachments/enclosures  include  drawings,  sketches,  photographs,  slides,  viewgraphs,  presentations, 
specifications,  manuals,  studies,  analyses,  requests  for  change  of  class,  applications  for  inspection,  Contracts, 
scopes  of  work,  and  related  communications. 

3.  Communications  shall  be  assigned  serial  numbers  and  shall  be  indexed  by  the  serial  numbers  and  applicable 
dates.  A  cross-reference  shall  be  made  from  contractor  assigned  serial  numbers  to  actual  incoming 
communication’s  serial  numbers,  where  applicable. 


BLOCK  6  -  REVIEW  REQ.:  Allow  14  days  for  government  review  and  comment,  if  provided. 


BLOCK  7  -  SUBMIT  TAL  SCHEDULE:  3  days  after  incoming  or  outgoing  communications  have  been  issued  or 
received;  R/ASR  3  days  after  incoming  or  outgoing  communications  have  been  issued  or  received. 


X-15 


S9800-AC-M  AN-010 


BLOCK  8  -  DISTRIBUTION: 

Addressee 

Reg/Repro 

SUPSHIP 

0/1 

PMS385 

0/1 

NAVSEA  05D/V 

0/1 
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T-SHIP  CONOPS  Attachment  4 

Sample  Statement  of  Work  Wording  for  Tactical  Problem  Solving  Working  Group 

C-42  TACTICAL  PROBLEM  SOLVING  WORKING  GROUP  (applicable  to  Phase  II) 

The  contractor  shall  be  an  active  participant  in  support  of  the  PEO  Ships  (PMS385)  MPF(F)  MFP 
Tactical  Problem  Solving  Working  Group  (WG)  during  the  DD&C  to  support  cost-effective  resolution 
of  regulatory  issues  in  regards  to  design,  construction  and  certification  of  the  vessel  in  accordance  with 
the  requirements.  The  WG  shall  consist  of  members  of  the  following  organizations  that  are  empowered 
to  make  decisions  and  commit  resources  on  behalf  of  their  organizations.  The  Navy,  MSC,  ABS  and  the 
contractor  will  assign  permanent  representatives  and  alternates.  The  WG  will  meet  bi-weekly  via 
telephone  and  semi-annually  at  the  contractor’s  facility.  The  WG  will  analyze  the  issues  and  risks  that 
arise  during  the  performance  of  the  contract,  evaluate  alternative  solutions,  and  propose  and  recommend 
solutions.  The  WG  will  evaluate  all  of  the  factors  associated  with  regulatory  requirements  for  the 
program  in  a  disciplined  and  structured  manner  and  will  share  information  and  recommended  solutions 
in  order  to  assist  in  resolving  the  issues. 


X-17/(X-18  blank) 


S9800-AC-MAN-01 0 


APPENDIX  Y 

PRESENTATION  GUIDELINES 


Title  Slide 

•  Who  gave  the  briefing 

•  The  date  of  the  briefing 

•  Include  NAVSEA  logo 

•  Good  descriptive  title 

•  Who  you  are  giving  the  brief  to  (optional) 

•  Classification  and/or  Distribution  Statement 
All  Follow  on  Slides 

•  Classification  and/or  Distribution  Statement 

•  Date  of  the  briefing  (at  least  month  and  year) 

•  Page  Number 

•  NAVSEA  Logo 

•  Last  name  of  presenter  (optional) 

First  Slide  (possibly  two) 

Address  the  following: 

•  Is  this  for  information  or  is  a  decision  needed? 

•  Make  sure  the  audience  knows  what  level  of  their  participation  is  required. 

•  What  is  the  issue? 

•  What  is  the  answer? 

•  What  is  the  urgency  of  the  issue? 

Outline  Slide 

•  Provide  an  outline  for  the  remainder  of  the  presentation. 

Follow  On  Slides 

•  Treat  each  slide  as  a  paragraph  -  one  distinct  message  per  slide. 

•  The  message  for  each  slide  should  be  clear  -  possibly  use  bumper  stickers. 

•  The  message  of  the  succeeding  slides  should  follow  a  logical  progression  to  support  the  conclusions  or 
provide  the  background  for  making  a  decision. 

•  Use  images  instead  of  words  where  possible. 

•  Only  include  information  needed  to  convey  the  message  -  eliminate  distracting  details. 

•  In  general,  don’t  repeat  information  unless  you  have  a  good  reason. 
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Decision  Slides 

•  If  a  decision  is  needed,  include  a  decision  slide  in  the  appropriate  place  in  the  presentation. 

•  The  decision  slide  should  clearly  articulate  the  decision  needed  and  provide  check  boxes  next  to  the 
different  options. 

•  During  the  presentation,  consider  checking  the  box  for  the  decision  made  and  have  a  decision  official 
sign  the  slide. 

Closing  the  Presentation 

•  Should  include  a  summary  -  restate  issue  and  the  answer. 

•  If  a  decision  presentation,  review  the  decision  made. 

•  If  applicable,  should  include  “what’s  next.” 
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Notes 

•  The  reasons  for  putting  the  answer  up  front  include: 

-  Many  times  you’ll  only  have  a  fraction  of  the  time  you  originally  thought  you  had.  If  you  get  the 
answer  out  at  the  start,  you  make  sure  you  have  conveyed  your  message. 

-  By  knowing  the  answer,  the  audience  has  the  framework  to  interpret  the  rest  of  the  slides. 
Hopefully,  you’ll  stop  the  tendency  of  the  audience  to  wonder  where  the  presentation  is  leading 
them.  Many  times,  your  audience  will  focus  on  a  specific  aspect  of  the  solution;  this  gives  you  the 
opportunity  to  jump  to  the  appropriate  slide  in  the  presentation  (or  even  to  a  backup  slide  if 
necessary). 

•  Many  engineers  structure  their  presentation  like  a  photo-album;  they  present  their  journey  through  the 
study.  Unfortunately,  while  this  may  be  interesting  to  the  presenter,  it’s  not  effective  in  rapidly 
conveying  information.  Only  that  information  which  is  central  to  the  conclusions  made  by  the 
presentation  should  be  incorporated.  The  presentation  should  be  structured  around  the  conclusions,  not 
the  process  used  to  develop  the  conclusions.  In  other  words,  the  presentation  should  be  like  a  story,  but 
the  plot  of  the  story  should  be  the  topic  itself,  not  the  analysis  of  the  topic. 

•  If  data  is  of  questionable  quality  or  does  not  directly  address  the  issue  at  hand,  leave  it  out. 

•  You  must  be  honest.  DO  NOT  suppress  information  that  appears  to  run  counter  to  your  conclusions. 
Rather,  show  the  information  and  give  the  reasons  why  you  believe  the  information  does  not  invalidate 
your  conclusions. 

•  Never  include  any  data  that  you  don’t  understand  or  can’t  clearly  explain. 

•  Don’t  read  the  slides,  tell  the  story. 

•  Use  page  numbers  on  all  slides.  For  CM  reasons,  also  consider  putting  the  date  and  filename  on  all 
slides.  Adding  organizational  logos  to  every  slide  further  helps  ensure  that  the  originator  of  a  hard 
copy  slide  that’s  been  faxed  multiple  times  can  be  determined. 

•  Have  a  good  understanding  of  the  accuracy  of  your  results. 

•  When  comparing  results  on  options,  you  need  to  focus  on  statistical  significance  of  the  differences.  If 
numbers  are  presented,  ensure  precision  of  display  does  not  exceed  the  accuracy  of  the  metric.  Don’t 
claim  one  option  is  better  than  another  if  the  differences  in  the  metrics  are  not  statistically  significant. 

•  Provide  interpretations  of  results.  What  generalized  lessons  can  be  learned?  Often  we  aren’t 
concerned  with  the  particular  details  of  the  concept  studied;  rather  we  are  interested  on  what  is  learned 
to  impact  decisions  at  hand.  Are  the  results  a  function  of  the  details  or  can  they  provide  the  generalized 
answers? 

•  Don’t  use  too  many  slides.  Use  the  fewest  necessary  to  make  your  point.  In  no  case  should  you  have 
more  than  1  slide  per  minute  of  presentation.  Ideally,  the  ratio  should  be  about  1  slide  per  2  to  3 
minutes  -  it  allows  you  to  tell  the  story  and  allows  the  story  to  be  heard  instead  of  just  “getting  through 
the  slides.” 

•  One  should  strive  to  have  an  engineering  level  of  detail  about  an  order  of  magnitude  greater  than  that 
which  is  presented.  This  helps  ensure  that  what  you  present  has  a  solid  foundation,  not  just  a  fantasy, 
and  can  likely  remain  accurate  even  if  one  of  the  lower  level  details  is  found  to  be  inaccurate.  The 
increased  level  of  detail  could  be  included  in  backup  charts,  should  questions  come  up. 

•  If  you  use  data  generated  by  another  study,  make  sure  you  reference  that  other  study. 

•  If  you  use  color  slides,  make  sure  the  message  still  can  be  determined  if  it  is  photocopied  or  printed  in 
black  and  white. 
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APPENDIX  Z 

TECHNICAL  REPORT  AND  DESIGN  REPORT  FORMATS 

The  general  format  for  a  technical  report  is  defined  in  Data  Item  Description  DI-MISC-8071 1  which  in  turn 
specifies  that  reports  should  be  in  accordance  with  “ANSI/National  Information  Standards  Organization  (NISO) 
Z39.18  Scientific  and  Technical  Reports  —  Elements,  Organization,  and  Design.”  The  following  format  is 
consistent  with  ANSI/NISO  7.39.18  and  should  be  considered  the  minimum  standard  for  reports  (Additional 
elements  from  ANSI/NISO  7.39.18  should  be  included  as  needed): 

Title  Page  with  authorship  statement,  signatures,  and  distribution  statement 

Report  Documentation  Page  (Standard  Form  [SF]  298) 

Abstract 

Table  of  Contents 
Fist  of  Figures  and  Tables 
Executive  Summary 
1.0  Introduction 

1.1  Objectives 

1.2  Approach 

1.3  Key  Assumptions 

1.4  Background 

2.0  Related  Requirements 

3.0  Evaluation  Procedures  (including  identification  of  tools  and  tool  versions  used) 

4.0  Alternatives 

5.0  Results  and  Discussion 

6.0  Conclusions/Recommendation 

References 

Appendixes  (including  electronic  data  files  for  analysis  tools) 

Fist(s)  of  Symbols,  Abbreviations,  and  Acronyms 

TYPICAL  DESIGN  REPORT  OUTLINE  (consistent  with  ANSI/NISO  Z39.18) 

Title  Page 

SF  298,  Report  Documentation  Page 
Abstract 

Table  of  Contents 
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Inboard  Profile 
Deck  Plans 

Area/Volume  Summary 
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List(s)  of  Symbols,  Abbreviations,  and  Acronyms 

REPORT  FORMAT 

General  -  Try  to  keep  the  report  at  the  CONFIDENTIAL  or  below  level  of  classification  for  expeditious  handling. 
SECRET  classified  references  or  detachable  CONFIDENTIAL,  or  SECRET,  appendices  are  preferred  over 
inclusion  in  the  report.  Ensure  classification  markings  are  accomplished  in  accordance  with 
SECNAVM-55 10.36. 

The  International  Traffic  in  Arms  Regulations  are  codified  in  the  Code  of  Federal  Regulation  (22  CFR  Ch.  I,  part 
120-130) 

The  items  covered  under  ITAR  are  described  in  Part  121  and  constitute  the  United  States  Munitions  List.  Part 
121  includes  virtually  all  ships  that  would  fall  under  the  cognizance  of  an  SDM.  Other  systems  or  subsystems 
may  also  be  included  in  Part  121.  Part  120.3  describes  the  policy  for  designating  items  to  be  on  the  United  States 
Munitions  List: 

“120.3  Policy  on  designating  and  determining  defense  articles  and  services. 

An  article  or  service  may  be  designated  or  determined  in  the  future  to  be  a  defense  article  (see  §  120.6)  or  defense 
service  (see  §  120.9)  if  it: 

(a)  Is  specifically  designed,  developed,  configured,  adapted,  or  modified  for  a  military  application,  and 

(i)  Does  not  have  predominant  civil  applications,  and 

(ii)  Does  not  have  performance  equivalent  (defined  by  form,  fit  and  function)  to  those  of  an  article 
or  service  used  for  civil  applications;  or 

(b)  Is  specifically  designed,  developed,  configured,  adapted,  or  modified  for  a  military  application,  and  has 
significant  military  or  intelligence  applicability  such  that  control  under  this  subchapter  is  necessary.” 

Any  technical  report  that  discusses  items  covered  by  ITAR  shall  include  the  following  statement  on  the  cover: 

"WARNING  -  This  document  contains  technical  data  whose  export  is  restricted  by  the  Arms  Export  Control  Act 
(Title  22,  U.S.C.  Sec.  2751  et  seq.)  or  the  Export  Administration  Act  of  1979,  as  amended,  Title  50,  U.S.C.,  App 
2401,  et  seq.  Violations  of  these  export  laws  are  subject  to  severe  criminal  penalties.  Disseminate  per  the 
provisions  of  OPNAV1NST  5510.161." 

References  to  previous  work  should  be  used  to  prevent  excessive  redundant  information. 
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The  exclusive  use  of  standard  8.5  inch  by  1 1  inch  paper  is  highly  encouraged  to  facilitate  printing  and  viewing  on 
computer  monitors.  The  report  body  should  use  standard  serif  fonts  such  as  Times  New  Roman.  Likewise  the 
size  of  the  report  body  text  should  be  between  10  and  12  points  (headings  and  titles  can  be  larger).  The  use  of  12 
point  Times  New  Roman  type,  single  space,  with  6  point  spacing  before  and  after  each  paragraph  is  encouraged. 
The  use  of  color  is  encouraged,  but  the  report  must  be  legible  and  understandable  if  printed  in  black  and  white. 

Distribution  Memo  -  The  Distribution  Memo  provides  the  means  for  capturing  the  report  within  the 
correspondence  file  and  implementing  report  distribution.  It  is  formatted  using  standard  Navy  Memorandum 
formats,  includes  a  serial  number,  date,  releasing  authority  signature(s),  and  distribution  instructions.  The  body  of 
the  memo  indicates  who  tasked  the  report,  and  a  short  abstract  of  its  contents.  If  the  report  has  been  coordinated 
with  other  organizations,  that  should  be  indicated  in  the  memo.  The  Distribution  Memo  includes  the  report  as  an 
enclosure. 

Title  Page  -  The  title  page  must  contain  the  report  title,  report  date,  NAVSEA  Logo,  Organizational  Address, 
distribution  statement,  and  classification  statement.  Guidance  for  distribution  statements  can  be  found  in 
DoDD  5230.24.  Whenever  possible,  a  graphic  image  of  the  design  will  be  prominently  displayed  on  the  title 
page.  An  example  of  a  title  page  is  shown  in  Figure  Z- 1 . 
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SF  298,  Report  Documentation  Page  -  All  reports  shall  include  a  completed  SF  298.  Where  a  report  has  been 
prepared  by  a  contractor,  that  contractor  may  be  credited  on  this  page  only.  Otherwise,  all  contractor  markings, 
letterhead,  labels,  etc.  shall  be  removed  prior  to  distribution.  Reports  marked  for  public  distribution  must  be 
approved  for  public  release  by  a  NAVSEA  Public  Affairs  Officer. 

Abstract  -  An  abstract  is  a  concise,  informative  statement  (about  200  words)  stating  the  purpose,  scope,  methods 
and  major  findings  of  the  report,  including  results,  conclusions,  and  recommendations.  The  abstract  is  usually 
included  as  part  of  the  SF  298. 

Table  of  Contents  -  This  table  shall  be  broken  into  sections,  subsections,  and  appendices  with  the  corresponding 
page  number. 

List  of  Tables  and  Figures  -  This  list  shall  have  a  number,  title,  and  corresponding  page  number  for  each  table  and 
figure. 

Foreword  -  This  section  shall  be  located  on  a  separate  page  after  the  List  of  Tables.  It  shall  include  background 
or  context  for  the  report,  task  history,  and  other  information,  e.g.,  organizations  involved  in  the  effort. 

Acknowledgements  -  This  section  shall  include  a  list  of  individuals,  companies,  and  government  activities  that 
made  a  significant  contribution  to  the  report.  Where  a  NAVSEA  code  provides  the  information  for  a  particular 
section,  that  input  should  be  recognized  in  the  applicable  section. 

Executive  Summary  -  The  executive  summary  shall  include  a  description  of  tasking  leading  to  preparation  of  the 
report,  author  of  the  study,  general  guidance/documents  used  (e.g.,  ICD  or  CDD),  and  the  fundamental  design 
parameters  resulting  from  this  guidance.  Principal  features  and  mission  critical  subsystems  shall  be  described.  If 
the  Baseline  Ship  is  not  the  recommended  configuration,  then  the  Baseline  Ship,  plus  trade-offs  and  the  resulting 
feasible  ship  with  its  principal  characteristics  and  capabilities  compared  with  the  stated  or  derived  requirements 
shall  be  presented.  Critical  issues,  highlights,  or  concerns  shall  be  included,  such  as  major  deviations  from 
NAVSEA  policies,  design  imbalances,  RDT&E  issues,  cost  questions,  schedule  constraints,  or  technical  risks.  In 
this  regard,  the  valued  judgment  of  the  ship  designer  on  the  overall  reasonableness  of  the  design  is  appropriate 
and  desirable.  The  summary  is  not  the  presentation  of  “just  the  facts”,  but  also  the  technical  “conclusions”  to  be 
drawn  from  those  facts  as  seen  by  the  persons  most  intimately  knowledgeable  about  the  design.  Note,  however, 
that  the  balance  of  the  report  should  be  factual  rather  than  subjective  in  nature,  except  for  “Conclusions  and 
Recommendations”. 

1.  INTRODUCTION 

The  introduction  shall  state  what  the  Study  presents,  with  a  brief  description  of  the  sections  involved. 

1.1  Background 

The  background  should  state  the  uses  of  the  proposed  ship,  comparing  it  to  similar  ships  of  the  past  or  ships 
further  along  in  the  acquisition  process.  Discuss  the  details  of  tasking. 

1.2  Objectives 

A  list  of  objectives  and  goals,  which  were  established  at  the  start  of  the  Feasibility  Study,  are  stated  in  this 
section. 

1.3  Approach 

Describe  the  basic  approach  to  establishment  of  design  requirements  and  alternatives,  trade-offs,  and  development 
of  design.  Flow  did  the  operational  requirements  of  the  ICD  or  CDD  get  translated  into  design  requirements? 

1 .4  Summary  Characteristics 

When  the  study  includes  major  variants  in  either  the  combat  system  or  the  hull,  mechanical,  and  electrical 
systems,  then  the  Variant,  Flight,  Option,  or  Alternative  definitions  must  be  provided.  A  tabular  presentation  of 
principal  characteristics  and  key  features,  accompanied  by  an  outboard  profile  and  plan  view,  is  expected. 
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2.  REQUIREMENTS  SUMMARY 

The  requirements  for  the  ship  shall  be  briefly  discussed  here,  in  addition  to  a  general  paragraph  explaining  the 
origin  of  the  requirements.  Top-level  constraints  (e.g.,  weight,  cost,  manning,  etc.)  would  be  highlighted  here  and 
then  discussed  subsequently,  in  the  appropriate  section. 

Note:  Only  include  a  brief  summary.  Any  guidance  not  in  the  ICD  or  CDD  should  be  discussed  and  source 
documented.  The  ICD  or  CDD  is  to  be  included  as  Appendix  A. 

2.1  Force  Interaction 

If  the  ship  is  to  deploy  with  military  (e.g.,  U.S.  Navy,  USCG,  or  NATO  ships  and  aircraft)  and/or  commercial 
(e.g.,  merchant,  MSC  operated,  or  University  operated  ships  and  aircraft)  units,  as  either  a  command  or  a 
coordinated  unit,  then  those  requirements  are  presented  here. 

2.2  Concept  of  Operations 

The  primary  and  secondary  naval  warfare  tasks  and  mission  areas,  in  general,  are  documented  along  with  a 
general,  brief  discussion  of  the  theater  of  operations.  The  reader  needs  to  understand  how  the  ship  will  be  used 
typically. 

2.3  Mission  Requirements 

These  shall  be  broken  down  into  two  parts: 

2.3.1  Functional  Requirements 

These  are  the  specific  primary  mission  descriptions,  including  the  characteristics  that  will  be  required,  and 
specific  secondary  mission  descriptions. 

2.3.2  Environmental  Factors 

These  include  hydrographical  and  weather  factors  such  as:  wind,  sea  state,  visibility,  and  temperature. 

2.4  Target/Threat  Statements 

These  shall  be  stated  for  the  particular  ship  being  designed.  The  requirements  for  target/threat  shall  be  listed 
including  typical  targets  and  where  threats  would  possibly  originate. 

2.5  Operating  Profile 

This  profile  shall  be  developed  to  determine  the  percentage  of  time  that  the  ship  will  be  operating  during  a  given 
year.  It  shall  include  the  major  logistic  factors  that  result  from  the  primary  mission  requirement,  how  the  ship  will 
draw  its  operational  logistic  support  from  other  units,  and  the  length  of  time  between  minor  and  major  overhauls. 
The  expected  life  of  the  ship  and  its  different  phases  shall  be  shown  in  a  figure  and  the  underway  availability  of 
the  ship  shown  in  a  graphic  table  on  the  figure. 

2.6  Design/Program  Requirements/Criteria/Constraints 

This  section  lists  any  specific  program  requirements/criteria/constraints  that  bounded  the  design  solution  space. 
Examples  include  specific  hull,  propulsion,  range,  environmental  control,  ship  control,  complement, 
accommodations,  mission  equipment  electrical  power,  ship  service  electric  power,  navigation,  communications, 
scientific  spaces,  and/or  weights,  deck  systems,  rescue/workboats,  noise,  electromagnetic  compatibility, 
Classification  or  certification  requirements  cited  in  the  ICD  or  CDD  shall  be  highlighted  here  as  design 
requirements,  criteria,  goals,  or  constraints. 
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3.  TECHNOLOGY  BASE 

A  summary  table  or  matrix  shall  be  included  near  the  beginning  of  this  section  showing  the  key  technology 
options  or  characteristics  examined.  Each  option  can  be  further  explained  in  the  following  sections. 

3.1  Projected  Technology  Dates 

This  is  typically  the  initial  operational  capability  date  but  may  be  earlier  if  the  design  is  restricted  to  items  or 
equipment  that  have  been  approved  for  production  or  are  in  a  funded  development  program  or  are  in  a  funded 
component  improvement  program. 

3.2  Technical  Risk  Constraints 

These  may  be  configuration,  operation,  or  equipment  development  risks.  These  risks  or  areas  of  uncertainty  will 
require  additional  study  during  later  stages  of  design  but  do  not  necessarily  require  an  R&D  program. 

3.3  Projected  Technology  Considered 

Major  acquisition  programs  usually  include  something  “new”.  The  impact  of  that  new  or  projected  technology  on 
the  ship  design  is  presented  here.  It  may  be  several  items,  equipments,  procedures,  capabilities,  or  technologies. 

It  may  be  a  combination  or  integration  of  items,  equipments,  procedures,  or  technologies  that  gives  the  design 
impetus. 

3.4  Projected  Technology  Used 

A  simple  recap  of  the  selected  technologies  is  provided  here. 

3.5  Technology  Readiness  Assessment 

For  each  of  the  new  technologies,  the  TRL  should  be  identified  with  supporting  rationale.  The  report  should 
indicate  if  this  assessment  was  conducted  as  part  of  a  form  TRA  or  performed  by  the  Design  Team. 

4.  SHIP  DESIGN  DESCRIPTION 

This  section  shall  include  information  on  performance,  configuration,  margins,  manning,  size,  stability, 
hydrodynamic  performance,  and  whole  ship  engineering.  Sketch(es)  identifying  the  baseline  design  and  the 
differences  among  the  Variants,  Flights,  Options,  or  Alternatives  will  be  included  here. 

4.1  Mission  Effectiveness 

The  purpose  of  this  section  is  to  compare  the  expected  performance  against  the  performance  in  the  ICD  or  CDD. 

4.1.1  Primary  Missions 

4.1.2  Secondary  Missions 

4.2  Configuration 

General  comments  on  configuration  drivers  (e.g.,  foil  configuration,  aircraft  flight  paths,  arcs  of  fire  for 
armament,  etc.)  are  cited  here  and  then  developed  subsequently. 

4.2.1  Combat  System  Arrangements 

The  combat  system  spaces  and  the  rationale  for  their  arrangement  in  the  context  of  the  total  ship  must  be  clearly 
presented.  This  rationale  will  generally  carry  through  subsequent  design  phases  to  preserve  functional  capability. 
The  major  combat  system  equipment  is  listed;  any  item,  which  is  included  for  space  and  weight  reservation 
purposes,  must  be  clearly  marked.  Based  on  the  notional  combat  system  equipment,  the  expected  performance 
results  are  to  be  compared  with  required  performance.  Topside  design  features/requirements  must  also  be  stated. 
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4.2.2  Ship  Arrangements 

The  machinery  or  non-combat,  mission  related  system  spaces  and  the  rationale  for  their  arrangement  in  the 
context  of  the  total  ship  must  be  clearly  presented.  This  rationale,  too,  will  generally  carry  through  subsequent 
design  phases.  The  major  machinery/auxiliary  or  non-combat,  mission  related  system  equipment  is  listed;  any 
item,  which  is  included  for  space  and  weight  reservation  purposes,  must  be  clearly  marked.  A  brief  description  of 
the  influence  of  stability,  seakeeping,  maneuverability,  survivability,  signatures,  or  electromagnetic  compatibility 
on  the  overall  ship  arrangements  will  be  presented  here  and  developed  subsequently. 

4.2.3  Topside  Design 

4.3  Margins 

A  summary  table  or  matrix  of  the  applicable  margins  will  be  included. 

4.3.1  Performance  Margins 

Margins  for  propulsion  power,  noise,  Radar  Cross  Section  (RCS),  or  any  other  applicable  performance  parameters 
will  be  aggregated  here. 

4.3.2  Acquisition  Margins 

Margins  for  weight,  CG,  Accommodations,  electric  load,  space,  or  any  other  ship  “internal”  design  parameter  will 
be  presented  here. 

4.3.3  Service  Life  Allowance 

All  weight,  CG,  electric  plant,  space,  or  other  margins  reserved  for  post-delivery  use  will  be  discussed  here. 

4.4  Manning 

A  summary  table  or  matrix  is  appropriate. 

4.4.1  Assumptions 

Where  habitability  or  manning  requirements  (e.g.,  MSC  standards)  have  been  invoked,  the  impact  on  the  design 
shall  be  presented  here.  The  assumptions  on  ship’s  organization  (e.g.,  Combat  Systems  Department  vs.  Weapons 
Department),  Flag,  Aviation  or  Marine  Detachments,  or  Troops  will  be  documented  here. 

4.4.2  Manning  Estimate 

The  estimating  techniques  will  be  cited  along  with  the  baseline  ship  source. 

4.4  .3  Accommodations 

This  is  a  simple  tabulation  of  accommodations  for  the  baseline  ship  plus  each  variant,  flight,  option,  or  alternative. 

4.4.4  Impact  of  optimized  manpower  on  human  performance,  workload,  and  safety 

4.5  Size 

The  considerations  driving  the  principal  dimensions  are  cited  here  and  then  developed  subsequently. 

4.5.1  Hull  Form 

The  hull  form  shall  be  discussed  including  the  original  (parent)  of  the  hull  form  selected.  Principal  characteristics 
shall  be  shown  in  the  text  and  in  a  table,  along  with  a  body  plan  that  may  be  provided  in  an  appendix.  The 
minimum  requirement  for  this  section  is  a  body  plan  with  displacement  and  center  of  buoyancy  (CB )  estimates. 

4.5.2  Weights 

The  method  of  estimating  the  weight  and  CG  shall  be  discussed  along  with  the  results  of  the  estimate  and  how  it 
affects  the  ship.  The  weight  and  CG  numbers  shall  be  shown  in  tabular  format.  A  comparison  with  recent, 
similar  ships  is  appropriate.  A  clear  statement  of  weight  margins  shall  be  provided  here. 
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4.5.3  Space 

At  least  spring  style  sketches  of  the  general  arrangement  will  be  provided  (e.g.,  in  the  appropriate  appendix)  to 
illustrate  important  design  features.  Remarks  on  the  superstructure  or  deckhouse  size  and  location,  provisions  for 
weapons  or  cargo,  and  any  feature  that  affects  the  overall  size  or  performance  of  the  ship  will  be  highlighted  here. 
An  Area/Volume  Summary  tabulation  is  appropriate. 

4.6  Stability  and  Hydrodynamic  Performance 

The  puipose  of  this  section  is  to  describe  the  intact  and  damaged  stability  criteria  and  to  discuss  seakeeping  and 
related  hydrodynamic  performance  of  the  hull.  The  stability  criteria  (i.e.,  U.S.  Navy  or  U.S.  Coast  Guard)  must 
be  stated. 

4.6. 1  Reserve  Buoyancy 

Compartmentation  and  floodable  length  requirements  and  the  ship  impact  are  presented  here. 

4.6.2  Damage  Stability 

An  investigation  shall  be  made  of  the  damage  stability.  The  results  of  this  investigation  shall  be  discussed  here, 
specifically  including  limits  on  displacement  and  CG.  Graphic  depictions  may  be  necessary. 

4.6.3  Intact  Stability 

The  effects  of  high-speed  turns,  icing,  80  knot  or  100  knot  beam  winds,  etc.  are  presented  here. 

4.6.4  Seakeeping  and  Maneuverability 

Methods  of  calculating  seakeeping  and  maneuvering  performance  as  well  as  the  method  for  calculating 
hydrodynamic  loads  shall  be  discussed  along  with  results.  It  is  anticipated  that  a  family  of  curves  will  be 
necessary  to  show  performance  in  various  sea  states.  A  figure  to  show  the  speed/power  curve  and 
speed/endurance  curve  will  be  included  here.  For  designs  having  seakeeping,  maneuvering,  or  recovery  from 
control  surface  failure  requirements,  predicted  performance  results  will  be  presented  in  a  suitable  figure  or 
trajectory  plot. 

4.6.5  Powering  Estimate 

Calm  water  powering  estimates  with  allowances  for  appendages;  surfaced,  foil  borne  or  cushion  borne  operations, 
or  sea  state  will  be  presented.  Sources  used  in  deriving  the  propulsive  coefficient  will  be  documented.  A 
graphical  presentation  of  the  resultant  powering  estimate  is  appropriate. 

4.6.6  Dynamic  Stability 

The  results  of  any  dynamic  stability  analysis  or  testing  should  be  presented.  If  applicable  this  section  will  include 
descriptions  of  the  anticipated  Safe  Operating  Envelope. 

4.7  Systems  Engineering 

4.7.1  Survivability 

This  section  addresses  the  ship’s  ability  to  survive  in  a  man-made  hostile  environment  by  coping  with  all  phases 
of  an  engagement;  i.e.,  avoiding  damage  by  going  undetected,  avoiding  damage  by  shooting  down  incoming 
threats,  resisting  damage  by  means  of  passive  protection,  and  controlling  damage  after  it  occurs  to  permit  the  ship 
to  continue  to  fight  “hurt”.  These  phases  are  usually  described  in  terms  of  Susceptibility,  Vulnerability,  and 
Recoverability. 

Survivability  requirements  and  the  design  features  explicitly  incoiporated  in  response  to  these  requirements  will 
be  discussed  along  with  a  risk  assessment. 
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Signatures  are  an  important  part  of  Susceptibility  and  are  generally  a  function  of  the  whole  synthesized  ship. 
Signature  discussion  can  include  the  following: 

Underwater  Radiated  Noise 

Sonar  Self  Noise 

Airborne  (Compartment)  Noise 

Radar  Cross  Section 

Magnetic 

Infrared 

Electromagnetic  Radiation 

Hydrodynamics 

Other 

4.7.2  Supportability 

Supply  plus  Maintenance  and  Repair  shall  be  discussed  here.  The  Supply  portion  shall  discuss  all  consumables, 
storage  of  fuels  and  lubricants,  storage  of  ammunition,  missiles,  torpedoes,  etc.,  provisions  and  other 
consumables.  The  other  portion  shall  describe  the  capability  for  shipboard  maintenance  and  repair,  including 
designation  of  the  level  of  support  to  be  rendered  by  ship’s  force,  tender,  and  Shipbuilder.  Shipboard 
maintenance  also  includes  accessibility  for  maintenance,  equipment  removal  provisions,  etc.  Any  special 
provisions  f  or  removal  of  large  items  (e.g.,  gas  turbine  engines)  will  be  presented  here. 

4.7.3  RAM  shall  be  briefly  discussed.  Comparisons  with  other  ships  and  design  features  that  have  been  adopted 
to  improve  RAM  should  be  provided. 

4.7.4  Costs  (RDT&E,  Acquisition,  and  Life  Cycle) 

All  costs,  if  available,  of  various  ship  configurations  and  the  economic  effect  of  the  various  propulsion  and/or 
electric  plant  trade-off  studies  on  total  cost  should  be  shown. 

4.7.5  Electromagnetic  Compatibility 

The  electromagnetic  environment  including  electromagnetic  pulse  effects  shall  be  described,  including  the 
protection  features  to  be  incorporated  into  the  ship.  Based  on  known  (selected)  combat  system  and/or 
communication  equipment,  a  Frequency  Utilization  Chart  and  an  EMI  Matrix  shall  be  provided.  The  data  and 
level  of  detail  (system  definition)  incorporated  in  sections  5.4.4  and  5.7  are  the  basis  for  these  two  efforts. 

4.7.6  Measures  of  Effectiveness 

Where  total  ship  performance  can  be  expressed  in  terms  of  operational  goals  or  requirements,  those  expressions 
are  discussed  here.  Of  particular  interest  are  the  analytical  relations  between  ship  design  features  (e.g.,  number  of 
missiles  or  torpedoes  carried)  vs.  the  operational  requirements  (e.g.,  conduct  anti-air  warfare  [AAW]  or  anti¬ 
submarine  warfare  [ASW]).  These  analytical  relationships  are  expected  to  be  instrumental  in  sizing  the  combat 
system  and  balancing  the  complementary  hull,  mechanical,  and  electrical  requirements  within  the  total  ship. 

4.7.7  Human  Systems  Integration 

The  results  of  any  Human  Systems  Integration  analysis  should  be  included  here  as  well  as  the  design  strategy 
employed  to  ensure  the  design  is  compatible  with  effective  and  efficient  operation  by  the  crew. 
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4.7.8  Design  Tools  Used 

The  report  should  list  all  of  the  design  tools  used.  For  each  design  tool,  the  version  should  be  identified  as  well  as 
a  brief  discussion  of  how  the  tool  was  used  and  any  assumptions  that  were  made.  The  VV&A  status  of  the  tools 
should  be  included. 

4.7.9  Design  for  Producibility 

The  report  should  describe  design  attributes  to  enhance  the  producibility  of  the  ship. 

4.7. 10  Design  for  In-Service  Cost  Reduction 

The  report  should  describe  design  attributes  to  reduce  the  In-Service  Costs. 

4.7. 1 1  Design  Certification  Approach 

The  report  should  detail  the  approach  for  Design  Certification  to  include  whether  classification  societies  will  be 
employed.  If  appropriate,  a  design  certification  matrix  should  be  included. 

5.  SUBSYSTEM  DESCRIPTIONS 

The  following  sections  shall  follow  the  Expanded  Ship  Work  Breakdown  Structure  (ESWBS),  with  a  detailed 
description  of  the  design’s  attributes  in  each  ESWBS  category.  Each  section  shall  include  applicable 
requirements  and  assumptions.  Where  options  or  trade-offs  (e.g.,  diesel  vs.  gas  turbine  prime  movers,  wet  vs.  dry 
fire  mains,  etc.)  have  been  examined,  each  section  shall  include  a  discussion  of  the  topic  examined  with  regard  to 
the  option. 

5.1  Hull  Structure  (ESWBS  100) 

This  section  shall  discuss  the  type  of  material  to  be  used  in  construction.  This  section  shall  also  discuss  structural 
arrangement  and  design  detail,  deck  heights  and  holds,  structural  weight  and  how  the  calculations  were  performed 
to  arrive  at  the  estimated  weight.  Calculations  shall  be  of  sufficient  detail  to  support  a  minimum  one-digit 
ESWBS  weight  and  cost  estimate.  This  section  shall  also  discuss  the  analysis  of  structural  loads  that  may  include: 
longitudinal,  transverse,  pressure,  and  acceleration  or  joint  loads. 

5.2  Propulsion  Plant  (ESWBS  200) 

Results  from  the  propulsion  plant  trade-off  studies  and  the  number,  size,  and  type  of  propulsor(s)  are  to  be 
included  here.  The  number,  type,  and  size  of  the  propulsion  engine(s)  and  any  special  features  (e.g.,  integrated 
electric  or  propulsion  derived  ship  service  electric)  will  be  highlighted  with  a  risk  assessment. 

5.3  Electric  Plant  (ESWBS  300) 

Results  from  the  electrical  plant  trade-off  studies  are  to  be  included  here.  The  number,  type,  and  size  of  the  ship 
service  generator(s)  and  any  special  features  will  be  highlighted  with  a  risk  assessment. 

5.4  Command  and  Surveillance  (ESWBS  400) 

A  discussion  of  the  origin,  source,  or  rationale  for  the  C&S  suite  is  the  focus  of  this  section.  The  major  pieces  of 
electronics  shall  be  listed,  along  with  the  applicable  weight,  space,  volume,  electric,  and  HVAC  loads  for  each 
item.  Based  on  the  EMI  Matrix  and  the  Frequency  Utilization  Chart,  C&S  impacts  on  the  topside  design  shall  be 
documented  here. 

5.5  Auxiliary  Systems  (ESWBS  500) 

Such  information  as  is  available  on  the  HVAC,  refrigeration  plant,  Replenishment  at  sea,  fire  extinguishing 
system,  fresh  water  system,  environmental  pollution  control  system,  and  mooring  and  towing  system  are  to  be 
presented  here.  If  it  is  an  air-capable  ship,  then  the  number,  size,  and  type(s)  of  aircraft  along  with  the  necessary 
handling,  stowage,  and  maintenance  facilities  will  be  included  here.  If  it  is  a  cargo  ship,  then  the  cargo  handling, 
stowage,  and  maintenance  facilities  will  be  discussed  here. 


Z-12 


S9800-AC-MAN-01 0 


5.6  Outfit  and  Furnishings  (ESWBS  600) 

A  discussion  of  the  living,  commissary,  recreation,  and  service  spaces  shall  be  provided  along  with  a  comparison 
to  the  applicable  habitability  standard  (e.g.,  OPNAVINST  or  MSCINST).  A  summary  table  listing  the  number, 
type  of  accommodations,  and  square  feet  per  person  will  be  included  here. 

5.7  Armament  (ESWBS  700) 

A  discussion  of  the  origin,  source,  or  rationale  for  the  weapon  suite  is  the  focus  of  this  section.  The  major 
weapons  shall  be  listed  along  with  the  applicable  weight,  space,  volume,  electric,  and  HVAC  loads  for  each  item. 

5.8  Loads 

All  the  various  load  items  are  summarized  here,  particularly  weapon  load  out/mix  assumptions,  endurance  fuel, 
ballasting  criteria,  or  any  unusual  condition. 

6.  R&D  NEEDS 

The  purpose  of  this  section  is  to  identify  specific  research  and  development  initiatives  essential  to  the  project. 

The  presentation  may  be  divided  into  combat  system  and  ship  R&D  needs.  In  some  cases,  existing  programs  will 
be  identified  for  supplemental  funding  to  expedite  development  matching  project  schedules.  In  other  cases,  new 
R&D  initiatives  may  be  necessary. 

7.  RISK  ASSESSMENT 

A  risk  element  is  any  feature  or  characteristic  specified  in  the  design  that  is  subject  to  a  business,  schedule  or 
technical  risk  or  both.  Business  risk  is  the  uncertainty  relating  to  lack  of  knowledge  or  control  of  the  end  cost  of 
the  item  to  the  government.  Technical  risk  is  the  uncertainty  relating  to  the  ability  to  obtain  satisfactory 
performance  in  the  acquisition  or  end  use  of  the  item  (including  design,  development,  test  and  evaluation  leading 
to  shipboard  installation,  use,  and  maintenance).  Each  risk  element  will  be  identified,  along  with  a  brief 
description  of  the  steps  necessary  to  reduce  the  risk  and  the  identification  of  the  Risk  Element  Manager  (normally 
a  TL  from  the  responsible  functional  code).  These  risk  elements  will  then  be  “fenced”  in  subsequent  design 
phases,  until  they  are  satisfactorily  resolved.  If  the  risk  element  requirement  requires  concurrent  RDT&E,  then  a 
POA&M  will  be  included  in  an  appropriate  appendix. 

8.  CONCLUSIONS  &  RECOMMENDATIONS 

This  section  will  by  its  nature  include  subjective  evaluations  by  the  author  of  the  “value”  of  ship  options  under 
study.  However,  there  should  be  clear  linkage  to  factual  information  previously  presented  in  the  report. 

8.1  Conclusions 

Based  on  the  results  of  the  Feasibility  Study,  briefly  discuss  the  conclusions  of  the  study’s  options  relative  to 
stated  requirements.  Deviations  from  accepted  practice  and  major  risks  from  section  7  shall  be  identified  for  each 
of  the  study’s  options. 

8.2  Recommendations 

The  recommendation(s)  shall  be  based  upon  the  conclusion(s)  and  economic  considerations.  State  the 
recommended  option. 

REFERENCES  -  The  references  are  to  be  listed  by  author,  report  title,  report  or  document  number  (if  applicable), 
enclosure  (if  applicable),  date,  and  security  status,  if  any.  For  example: 

2.  “Operating  Requirement  for  Acoustic  Research  Vessel  (YAG)  Er  1  to  CNO  ltr  Ser  224D/38301 1,  23  June  1982 
(Confidential) 
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APPENDIX  AA 

CONTRACTING  CONSIDERATIONS 


AA.1  INCENTIVES. 

The  SDM  should  actively  participate  in  the  definition  of  contract  incentives.  Performance,  cost,  and  schedule 
incentives  must  be  employed  with  great  care.  There  is  always  the  danger  that  setting  incentives  in  one  area  will 
result  in  compromise  elsewhere. 

Establishment  of  a  payment  schedule  for  performance  improvement  has  occasionally  been  used  with  success. 
Performance  incentives  are  normally  limited  to  no  more  than  a  few  areas  like  weight  control.  Flexible  incentives 
may  be  structured  to  target  areas  as  needed. 

It  is  more  common  to  establish  subjective  performance  categories  with  a  Navy  award  fee  panel  meeting 
periodically  to  award  a  percentage  of  an  allowable  pool.  The  SDM  should  chair  any  technical  evaluations.  The 
contract  may  be  set  up  to  allow  the  Navy  to  change  the  award  fee  categories  prior  to  the  next  performance  period. 
Some  contracts  provide  for  un-awarded  fee  to  be  “rolled”  to  a  final  assessment  at  the  end  of  the  contract.  This 
may  have  the  negative  effect  of  turning  consistently  low  ratings  into  a  much  higher  total  award. 

Cost  share  lines  are  commonly  established  to  share  cost  risk  between  the  Navy  and  the  Shipbuilder. 

AA.2  LEAD/FOLLOW  YARD  RELATIONSHIPS. 

For  large  procurements  like  DDG51,  which  must  be  built  at  multiple  Shipbuilders,  a  lead/follow  yard  arrangement 
may  be  set  up  to  permit  all  ships  to  be  constructed  to  the  same  Detail  Design.  There  are  a  number  of  pitfalls, 
including  how  to  deal  with  a  potential  “bid  to  lose  strategy.”  Where  a  contractor  expects  to  be  selected  as  the 
follow  yard,  he  has  little  incentive  to  “sharpen  his  pencil”  for  the  price  proposal.  One  approach  is  to  limit  follow 
yard  profit  to  less  than  the  lead  yard. 

AA.3  SUBCONTRACTING. 

Contracting  for  “industry  participation”  may  result  in  “industry”  subcontracting  to  local  design  agent  contractors. 
If  this  is  not  desired,  the  SDM  should  ensure  that  the  contract  limits  subcontracting  and/or  limits  substitutions  for 
those  personnel  that  are  bid. 

AA.4  “BUY  AMERICAN”  REQUIREMENTS. 

The  SDM  should  become  familiar  with  current  “Buy  American”  legislation  for  its  effects  on  the  specifications 
and  contract. 

AA.5  AVOIDANCE  OF  “TECHNICAL  LEVELING”  DURING  COMPETITION. 

In  the  competitive  phases,  SDMs  must  take  care  not  to  provide  favorable  information  to  one  contractor  or  another. 
Information  provided  to  all  contractors  in  the  competition  must  be  consistent  in  content  and  over  time.  SDMs  can 
and  should  let  contractors  know  when  the  solution  they  propose  may  not  meet  requirements.  Information  released 
to  contractors  or  potential  bidders  must  be  disseminated  through  the  Program  Manager,  documented,  and  shared 
consistently. 
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AA.6  DATA  RIGHTS  AND  INTELLECTUAL  PROPERTY. 

The  SDM  should  ensure  that  the  government  retains  the  data  and  intellectual  property  rights  needed  to  support  the 
ship’s  life  cycle  and  any  follow-on  procurement.  This  has  proven  difficult  for  contractor  IDEs  and  Product 
Models.  Neglect  of  these  considerations  has  proven  costly. 

AA.7  OPEN  SYSTEMS,  PROGRAM  PROTECTION,  ITEM  UNIQUE  IDENTIFICATION,  AND  OTHER 
NEW  MANDATE  CONTRACTING  GUIDANCE. 

The  current  pattern  is  that  detailed  guidance  for  contracting  including  proposed  SOW  clauses  and,  where 
applicable,  source  selection  criteria  follows  the  issuance  of  every  new  mandate  within  months.  For  areas  under 
his  cognizance,  the  SDM  should  ensure  that  this  language  is  tailored  to  the  Program  to  produce  a  productive  result 
and  minimize  costs.  For  example,  open  systems  requirements  has  been  limited  to  selected  information  technology 
based  systems  and  then  implementation  required  only  if  a  business  case  analysis  demonstrates  that  it  have 
beneficial  life  cycle  cost  results. 
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APPENDIX  BB 

INTEGRATED  PRODUCT  AND  PROCESS  DEVELOPMENT,  IPTS,  AND 

WORKING  GROUPS 


BB.1  TRADITIONAL  DESIGN  PROCESS. 

Problems  with  the  traditional  design  process  have  included: 

•  Difficulty  in  designing  for  simplicity  and  reliability 

•  Failure  to  pay  enough  attention  at  the  design  stage  to  the  likely  quality  of  the  manufactured  product 

•  Excessive  development  times 

•  Weak  design  for  producibility 

•  Inadequate  attention  to  customers 

•  Weak  links  with  suppliers 

•  Neglect  of  continuous  improvement 

BB.2  INTEGRATED  PRODUCT  AND  PRODUCT  DEVELOPMENT. 

Basic  concurrent  engineering  or  Integrated  Product  and  Process  Development  (IPPD)  has  received  much  attention 
and  application  in  naval  ship  design  since  about  1992.  It  made  a  strong  start  on  overcoming  some  of  the  major 
problems  in  new  product  development  and  was  a  major  element  of  many  leading  companies’  improved 
competitiveness. 

IPPD  has  two  essential  characteristics: 

•  It  is  a  concurrent  process,  and 

•  It  is  carried  out  by  a  multifunctional  product  development  team  or  IPT. 

Product  design,  production-process  engineering.  Fleet-support  development,  and  all  other  elements  of  product 
success  are  addressed  from  the  beginning  as  an  integrated  set  of  activities  and  objectives.  The  ideal  is  simple:  to 
have  one  team  working  on  one  system  in  one  total  development  activity,  all  focused  on  benefit  to  the  customer. 
The  system  is  the  product,  the  production  capability,  and  the  Fleet-support  capability.  The  design  parameters, 
production  parameters,  and  Fleet-support  parameters  all  integrated  together  define  the  unified  IPPD  system.  It  is 
the  responsibility  of  the  IPT  to  define  and  quantify  all  of  the  parameters  in  one  total  development  activity. 
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The  major  benefits  of  IPPD  stem  from  a  few  principles: 

•  Start  all  life  cycle  tasks  as  early  as  possible 

•  Utilize  all  relevant  information  as  early  as  possible  in  an  IDE 

•  Empower  individuals  and  teams  to  participate  in  defining  the  objectives  of  their  work 

•  Achieve  operational  understanding  for  all  relevant  information 

•  Adhere  to  decisions  and  utilize  all  previous  relevant  work 

•  Make  decisions  in  a  single  trade-off  space;  that  is,  treat  design,  production,  and  Fleet  support  as  a 
single  system  within  which  trade-offs  can  be  made 

•  Make  lasting  decisions,  overcoming  a  natural  tendency  to  be  quick  and  novel 

•  Develop  trust  among  teammates 

•  Strive  for  team  consensus 

•  Use  a  visible  concurrent  process 

All  of  these  principles  may  seem  to  be  unexceptionable.  However,  relative  to  traditional  product  development, 
they  are  major  improvements. 

The  essence  of  the  concurrent  process  and  the  multifunctional  IPT  is  both  simple  and  subtle.  The  mind  literally 
cannot  work  on  two  tasks  concurrently  (at  least  not  consciously).  In  the  concurrent  process,  frequent  information 
exchanges  occur  at  the  level  of  the  small  unit  design  tasks  that  drive  the  need  for  an  Integrated  Data  Environment 
(IDE).  In  the  traditional  design  process  the  work  blocks  were  huge  before  information  transfer  occurred.  At  the 
micro  level  the  tasks  in  the  concurrent  process  are  sequential  or  iterative,  but  from  the  macro  perspective  the 
effect  is  the  concurrent  process.  The  rugby  image  of  cooperatively  moving  the  scrum  downfield  is  appropriate. 

BB.3  IPTs. 


It  may  seem  a  small  difference  whether  two  people  are  members  of  the  IPT  or,  alternatively,  are  assigned  to  the 
same  project  but  remain  in  separate  organizations,  but  that  difference  is  critical.  If  the  two  people  are  not 
members  of  the  same  IPT,  the  probability  is  greatly  increased  that  some  of  the  new  product  development 
principles  will  be  violated,  with  a  very  detrimental  effect  on  the  development  program.  When  an  individual’s 
primary  allegiance  is  to  a  cloistered  group  of  functional  specialists,  the  performance  within  the  specialty  may  be 
elegant,  but  there  is  usually  inadequate  benefit  to  the  overall  development  program.  This  is  sub  optimization. 

When  an  individual  is  a  member  of  the  IPT,  he  or  she  is  much  more  likely  to  participate  in  defining  the  objectives 
of  the  IPT’s  work  and  thus  the  objectives  are  likely  to  be  both  more  relevant  to  the  program  and  better  understood 
by  the  participants.  Often,  definition  of  the  objectives  is  the  most  difficult  part  of  any  task;  an  IPT  is  more  likely 
to  succeed  at  this  than  separate  groups  of  specialists. 

Membership  in  a  team  also  greatly  improves  the  exchange  of  information.  Specialists  like  to  communicate  in 
terms  that  are  dear  to  their  own  specialty  but  not  fully  understood  by  other  people.  Membership  in  the  IPT  greatly 
increases  the  probability  that  individuals  and  small  groups  will  help  others  to  effectively  use  the  output  from  their 
work,  going  beyond  a  perfunctory  communication.  This  greatly  improves  understanding  of  and  commitment  to 
the  decisions  that  they  make,  which  are  vital  success  factors. 


BB-2 


S9800-AC-MAN-01 0 


BB.4  CONCURRENT  PROCESS. 

In  the  best  practice  of  IPPD,  the  design  of  the  production  system  and  of  the  Fleet-support  system  starts  early, 
concurrently  with  the  design  of  the  product.  This  has  five  major  benefits: 

•  The  development  of  the  production  and  Fleet-support  system  has  an  early  start. 

•  Trade-offs  occur  among  design,  production,  and  logistics  concurrently,  as  one  system. 

•  Good  design  for  manufacturability  and  Fleet  supportability  is  facilitated. 

•  The  production  and  Fleet-support  people  gain  a  clear  understanding  of  the  design,  and  are  committed  to 
its  success. 

•  Prototype  iterations  or  engineering  change  orders/rework  are  reduced  because  the  design  is  more 
mature  before  the  first  full-system  is  built. 

Although  the  concurrent  process  is  emphasized  during  the  design  phase,  it  is  used  throughout  the  development  of 
the  new  product. 

The  concurrent  process  is  first  used  during  the  development  of  the  system  concept.  In  the  past  it  was  common  for 
market  research  to  determine  customer  or  user  needs  and  throw  its  conclusions  over  the  wall  to  planning,  which  in 
turn  outlined  the  requirements  for  the  product  and  then  threw  its  results  over  the  wall  to  product  design 
engineering.  This  sequence  of  first  determining  users’  requirements  and  then  developing  the  system  concept 
made  it  unlikely  that  the  needs  of  the  customer  or  user  were  adequately  considered  in  choosing  the  system.  The 
activities  of  determining  users’  requirements  and  developing  the  system  concept  are  now  in  the  best  practice 
combined  and  carried  out  by  one  multifunctional  IPT. 

The  best  concurrent  process  treats  development  as  one  activity  that  incorporates  product,  production  system,  and 
Fleet-support  system.  There  are  no  upstream  and  downstream  activities  in  the  traditional  sense.  Of  course,  in  the 
natural  flow  of  the  work  some  things  are  done  before  others.  For  example,  concepts  are  selected  before  detailed 
design,  and  production  tools  are  designed  before  they  are  built.  However,  the  best  concurrent  process  avoids  the 
unnatural  separation  of  work  into  upstream  and  downstream  in  accordance  with  organizational  rigidities. 

In  the  traditional  process,  tasks  were  clearly  labeled  product  development,  production-capability  development,  or 
Fleet-support  development,  and  tasks  of  the  first  type  (upstream)  were  completed  before  tasks  of  the  other  two 
types  (downstream)  were  started.  In  the  best  concurrent  process  the  tasks  are  not  defined  in  this  divisive  upstream 
and  downstream  style.  All  tasks  now  incorporate  the  product  view,  the  production  view,  and  the  Fleet-support 
view.  Subtasks  may  still  remain  “pure.”  For  example,  the  finite-element  analysis  (FEA)  is  typically  performed 
by  a  specialist.  However,  the  results  of  the  analysis  can  now  be  put  to  much  better  and  more  immediate  use.  The 
FEA  specialist  works  closely  with  a  subsystem  Design  Team-with  a  Hull  IPT,  for  example.  In  the  best  concurrent 
process,  producibility  and  functionality  are  optimized  together.  We  combine  the  FEA  with  the  design  of  the 
production  process  to  minimize  penetrations  of  the  hull  structure  and  the  cost  of  producing  it  at  the  same  time. 

The  FEA  specialist  works  closely  with  the  subsystem  team  to  define  the  objectives  of  the  FEA  and  then  presents 
the  results  to  the  team  in  a  form  they  can  easily  use.  The  FEA  specialist  further  works  with  the  team  to  help  in  the 
application  of  the  results,  probably  as  electronic  data.  For  the  duration  of  this  task  the  FEA  specialist  is 
effectively  a  member  of  the  team. 

Contrast  this  with  the  dysfunctions  of  the  traditional  design  process.  The  FEA  specialist  received  drawings  of  the 
preliminary  hull  design,  did  the  FEA  and  tossed  the  printout  over  the  wall  to  the  structural  design  engineer-there 
was  no  team,  so  producibility  was  not  considered. 

Multiply  this  vignette  by  a  thousand  and  the  contrasting  superiority  of  the  concurrent  process  is  apparent. 
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BB.5  TOTAL  SYSTEM  DESIGN. 

The  ideal  design  process  is  to  have  one  activity  that  addresses  all  parameters  in  the  total  system.  In 

traditional  product  development  the  total  set  of  parameters  that  must  be  defined  and  quantified  is  decomposed  in 
three  ways:  by  program  phase,  subsystem,  and  discipline.  We  can  visualize  this  as  a  three-dimensional  structure, 
with  each  cell  defined  by  a  single  phase,  subsystem,  and  discipline.  In  a  complex  system  this  easily  creates 
several  hundred  cells  each  with  its  dedicated  set  of  parameters.  Sub  optimization  is  done  within  each  cell,  with 
very  inadequate  attention  given  to  parameters  that  lie  outside  that  cell. 

The  best  concurrent  process  eliminates  partitioning  into  cells  defined  by  development  phase,  subsystem  and 
discipline.  All  parameters  that  are  relevant  to  a  decision  are  considered  in  making  the  decision.  (Which 
parameters  are  considered  relevant  is  determined  in  part  by  their  function  in  satisfying  customer  needs.)  The 
objective  is  to  make  the  design  process  seamless.  In  IPPD,  we  achieve  a  seamless  process  by  forming  the 
multifunctional  IPT  and  strongly  motivating  it  to  use  a  seamless  process.  (This  is  not  completely  sufficient; 
vigilant  information  processing  or  an  IDE  is  also  required). 

BB.6  PROBLEM  PREVENTION. 

The  problem-prevention  approach  emphasizes  considering  all  parameters  as  early  as  possible  and  thus  provides  a 
shift  of  activity  level  to  the  earlier  part  of  the  design.  Frank  Pipp  (1990),  who  led  the  implementation  of  basic 
concurrent  engineering  within  the  Xerox  Corporation  from  1980  to  1983,  cautions,  “Don’t  yield  to  the  temptation 
to  save  money  in  the  early  stages  of  a  product  program.  Invest  enough  time  and  money  to  be  sure  customer 
requirements  are  known  and  faithfully  translated  to  specifications.  Passing  on  immature  technology  will  surely 
cost  you  more  money  eventually  than  properly  completing  and  engineering  new  technologies.  One  thing  we  have 
learned  is  that  bad  engineering  and  design  go  all  the  way  to  the  customer;  it  never  seems  to  get  fixed  along  the 
way.” 

BB.7  OTHER  ELEMENTS  OF  IPPD  IMPROVEMENTS. 

In  addition  to  (1)  being  the  practice  of  the  concurrent  process  and  (2)  being  carried  out  by  a  multifunctional  IPT, 
basic  concurrent  engineering  or  IPPD  includes  other  improvements  over  traditional  product  development  that 
reinforce  these  two  major  thrusts.  These  additional  enablers  are  described  next. 

BB.7.1  FOCUS  Quality,  Cost,  and  Deliver  (QCD).  The  Program  should  focus  all  activities  on  the  quality,  cost, 
and  delivery  (development  schedule)  of  the  new  product.  This  overcomes  many  fragmented  bits  of  game  plans 
with  other,  more  local  objectives,  which  have  adverse  effects  on  quality,  cost,  and  deliver  (QCD).  In  the  past, 
much  work  that  appeared  very  elegant  by  some  functional  criteria  was  eventually  found  to  add  little  to  the  QCD 
of  the  product,  and  in  many  cases  was  actually  dysfunctional.  The  focus  on  QCD  is  part  of  the  general  approach 
of  using  all  relevant  information  to  make  decisions  that  satisfy  all  of  the  relevant  objectives. 

BB.7. 2  Emphasis  on  Customer  Satisfaction.  Inward-looking  organizational  metrics  are  de-emphasized  and 
are  replaced  by  responses  from  customers.  The  emphasis  on  customer  satisfaction  extends  throughout  all  of 
product  development,  and  all  other  organization  activities.  All  objectives  are  put  to  the  test  of  the  effect  upon  the 
customer.  The  team  devotes  much  effort  to  learning  and  understanding  the  opinions  of  customers.  In  developing 
the  Taurus  in  the  early  1980s,  Ford  developed  a  list  of  1401  features  that  car  buyers  were  looking  for.  The  team’s 
interest  in  the  customers’  views  extended  from  the  customers’  needs  at  the  start  of  a  new  development  to  the 
reactions  from  the  users  of  the  finished  product. 
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BB.7.3  Emphasis  on  Competitive  Benchmarking.  Not  only  arc  the  products  benchmarked  against  the  best  of 
the  competition,  but  also  all  processes  are  subject  to  being  benchmarked.  IPPD  itself  is  to  a  considerable  extent 
the  result  of  competitive  benchmarking,  which  is  applied  to  many  detailed  sub  processes  within  IPPD  and  is 
important  for  continuous  improvement.  The  Massachusetts  Institute  of  Technology  Commission  found  that 
parochialism  was  a  major  weakness  of  American  companies.  It  is  very  unlikely  that  a  large  percentage  of  all 
improvements  around  the  globe  will  occur  within  one  organization.  Therefore,  an  important  element  of  success  is 
vigilance  in  finding,  understanding,  bringing  in,  and  implementing  major  improvements.  To  a  large  extent  this 
Best  Ship  Design  Practices  is  the  result  of  benchmarking. 

BB.8  IPT  MANAGEMENT. 

BB.8. 1  IPPD  is  best  carried  out  by  a  multifunctional  IPT  led  by  a  strong  product  design  manager.  All  functions 
of  the  organization  should  participate.  People  who  are  doing  significant  work  for  the  specific  product 
development  project  should  be  part  of  the  IPT  while  they  are  doing  the  project’s  work.  There  is  a  vast 
psychological  difference  between  performing  a  task  within  a  support  group  and  performing  it  as  a  member  of  the 
IPT.  As  an  IPT  member,  the  contributor  will  (1)  understand  the  specific  requirement,  (2)  have  the  necessary  close 
communications  with  other  members  of  the  IPT,  and  (3)  be  dedicated  to  the  utilization  of  the  task  results  to  make 
design  decisions.  All  three  of  these  benefits  are  much  less  likely  to  materialize  if  the  contributor  remains  outside 
the  IPT. 

It  is  important  that  the  people  on  the  IPT  from  each  technical  function  be  able  to  (1)  represent  the  knowledge  of 
that  function  and  (2)  gain  the  commitment  of  that  function  to  the  decisions  that  are  made.  Dysfunctions  will 
occur  if  the  information  is  not  provided  or  is  wrong,  or  if  the  function  subsequently  disowns  the  decisions  and 
wants  major  changes.  For  example,  if  the  IPT  decides  to  use  an  aluminum  die-casting  and  if  later,  when  the 
product  enters  into  production,  the  production  operations  people  want  a  fiber-reinforced  polymer  part,  and  then 
rework  of  the  development  will  become  rampant.  The  strong,  complete  multifunctional  IPT  is  essential  for 
success. 

Some  people  will  stay  on  the  IPT  throughout  the  development  project,  while  others  will  be  on  the  team  only 
during  the  phase  or  task  that  requires  their  expertise.  The  important  criterion  is  that  there  should  not  be  any 
sudden  changes  in  the  composition  or  size  of  the  IPT,  since  that  would  reduce  teamwork  and  cause  lack  of 
continuity. 

Even  while  a  member  of  a  team,  the  individual  still  does  much  independent  work,  but  the  work  is  done  for  the 
team.  Membership  in  the  team  makes  the  goals  of  individual  work  more  holistic,  more  applicable  to  the  total 
system  or  product.  The  individual’s  work  is  integrated  into  the  team’s  activities  and  objectives.  The  individual’s 
work  contributes  effectively  to  the  overall  development  program. 

Although  we  refer  to  the  team,  it  is  actually  a  team  of  teams.  The  design  manager  who  leads  the  IPT  and  the 
systems  engineering  managers  who  report  directly  to  him  or  her  constitute  one  team.  They  are  responsible  for 
everything  related  to  the  total  product  and  its  development  program.  They  include  the  subsystem  leaders,  for  each 
product  subsystem  has  a  team.  Many  critical  interfaces  have  a  dedicated  team.  Teams  are  formed  wherever  they 
are  needed  to  achieve  an  integrated  approach  to  the  development  of  the  new  product.  Although  the  complete  IPT 
for  a  large,  complex  product  may  have  several  hundred  members,  it  is  rare  for  any  one  operational  team  to  have 
more  than  20  members.  Many  have  only  a  few  members.  The  formation  of  the  best  interlocking  structure  for 
integrating  the  teams  is  a  key  success  factor. 

The  DSM  matrix  can  be  a  useful  tool  for  identifying  the  ideal  boundaries  and  composition  of  each  of  the  member 
teams.  One  could  argue  that  the  greatest  need  for  integration  and  concurrency  across  multiple  disciplines  is 
within  the  boundaries  of  a  “Cluster.”  By  examining  the  resources  needed  as  part  of  the  Mechanisms  of  the  design 
activities  that  constitute  the  “Cluster,”  one  can  identify  which  organizations  are  needed  to  participate  in  the  IPT. 
Once  all  of  the  design  products  of  the  “Cluster”  are  completed,  the  IPT  should  be  disestablished. 
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BB.8.2  Avoid  Dysfunctional  Specializations.  The  effectiveness  of  an  IPT  is  strongly  influenced  by  the 
spectrum  of  generalization  and  specialization  that  characterizes  its  capabilities  and  leadership  style.  Prior  to  1940 
most  product  development  was  done  by  generalists,  and  the  problems  of  segmentalism  were  not  usually  severe. 
This  approach  sufficed  for  products  that  were  not  high  in  technical  sophistication.  However,  during  the  period 
1940-1960  the  shortcomings  of  this  approach  became  obvious,  and  the  emphasis  shifted  to  technical  depth  and 
sophistication.  However,  this  led  to  segmentalism  or  cloistered  groups  of  technical  specialists  looking  inward 
within  their  own  specialty.  This  caused  tremendous  problems  that  concurrent  engineering  or  IPPD  is  now 
overcoming. 

The  successful  IPT  uses  a  balanced  modulation  of  specialization,  with  clear  emphasis  on  total  ship  systems 
engineering.  Even  the  most  specialized  people  broaden  themselves  sufficiently  to  be  able  to  communicate 
effectively  with  the  in-house  customers  for  their  work.  Most  of  the  product  development  work  is  done  by  the  core 
of  the  IPT,  which  consists  of  people  who  are  not  narrow  specialists  but  combine  a  good  combination  of  breadth 
and  depth.  Thus,  the  traditional  product  design  engineers  become  quite  knowledgeable  about  production,  and 
traditional  production-process  engineers  become  knowledgeable  about  customer  needs  and  product  function.  This 
enables  them  to  function  effectively  as  a  team,  to  work  on  the  complete  set  of  parameters  as  one  system  to  be 
developed  in  one  activity. 

The  FEA  specialist,  mentioned  earlier,  is  a  good  example  of  the  new  model  in  specialization.  In  the  days  of 
dysfunctional  specialization,  the  FEA  specialist  was  an  example  of  the  segmented  specialist.  The  FEA  specialist 
did  not  understand  design  and  production,  and  the  design  and  production  people  did  not  understand  FEA. 
Therefore,  they  often  did  not  reach  a  common  definition  of  objectives,  and  the  FEA  results  were  thrown  over  the 
wall  in  a  format  that  the  design  and  production  people  did  not  interact  with  effectively.  Now,  in  the  new  model 
IPT,  they  have  all  broadened  sufficiently  to  reach  common  objectives,  and  to  use  the  FEA  to  quickly  improve  cost 
and  quality  early  in  the  development  process. 

The  example  of  FEA  can  be  taken  a  step  further.  Should  sophisticated  design  tasks  be  performed  by  specialists, 
or  should  they  be  moved  into  the  work  domain  of  the  core  IPT  people?  Should  the  design  engineer  do  the  FEA  or 
go  to  a  specialist?  If  the  design  engineer  can  do  the  FEA,  that  is  preferred,  because  it  sidesteps  some  of  the 
inefficiencies  of  human  interaction.  As  computers  become  more  user-friendly,  the  design  engineer  can 
incorporate  more  and  more  specialized  tasks  into  his  or  her  portfolio  of  capabilities.  Specialized  knowledge  is 
utilized  both  by  bringing  specialists  into  the  IPT  and  by  making  the  knowledge  available  to  the  core  IPT  people 
via  user-friendly  computers.  The  best  balance  between  the  two  is  constantly  evolving  in  a  process  of  continuous 
improvement.  The  same  principle  of  broadened  perspective  to  enable  effective  cooperative  work  applies  here 
also.  The  specialist  and  the  core  IPT  people  must  be  cooperative  to  produce  computer  systems  that  are  effective 
in  the  IPT  environment. 

BB.8.3  Strong  Product  Design  Managers  for  Success.  Clark  and  Fujimoto  (1991)  identified  four  modes  of 
development  organizations  in  the  global  automotive  industry.  In  all  four  of  these  modes  the  people  have  a 
functional  “home”;  the  modes  differ  in  the  degree  of  focus  on  a  specific  product.  The  modes  are  configurations 
employing  (1)  a  functional  design  structure,  (2)  a  lightweight  product  design  manager,  (3)  a  heavyweight  product 
design  manager,  and  (4)  a  project  execution  team.  Outside  the  automotive  industry,  and  therefore  not  identified 
by  Clark  and  Fujimoto,  yet  a  fifth  mode  is  used:  (5)  the  independent  IPT.  The  first  two  of  these  -  the  least 
product-focused  of  the  five  -  may  suffice  for  products  characterized  by  high  technical  sophistication,  low 
complexity,  and  relatively  static  concepts,  but  Clark  and  Fujimoto  found  that  these  modes  had  shortcomings  in 
automobile  development.  In  general,  they  will  not  offer  a  competitive  advantage,  so  they  will  not  be  discussed 
further. 
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In  two  of  the  more  product-focused  modes  -  heavy-weight  product  design  manager  and  project  execution  team  - 
the  development  people  are  managed  by  a  strong  product  design  manager.  In  the  project  execution  team  the 
people  are  temporarily  assigned  (seconded)  to  the  IPT.  In  the  fifth  mode,  the  independent  IPT,  which  goes 
beyond  the  structure  that  was  observed  by  Clark  and  Fujimoto  (1991)  in  the  automotive  industry,  the  development 
people  are  members  of  the  IPT  only;  they  do  not  have  a  functional  home,  which  makes  the  product  manager  even 
stronger. 

The  independent  IPT  (which  has  no  functional  home)  goes  the  furthest  in  adhering  to  the  principles  of  concurrent 
engineering  or  IPPD.  However,  any  of  the  three  product-focused  methods  of  organization  (of  the  five)  can 
undoubtedly  be  made  to  work  well.  All  three  product-focused  modes,  the  heavy  weight  product  design  manager, 
the  project  execution  team,  and  the  independent  IPT,  will  work  well  if  the  other  principles  of  IPPD  are  observed. 
The  organizational  structure  is  not  the  end  objective,  but  rather  a  means  to  the  end  of  implementing  the  principles 
of  IPPD  to  make  product  development  sufficiently  holistic  and  focused  on  customers  for  the  specific  product. 

Clark  and  Fujimoto  compiled  a  list  of  characteristics  of  effective  product  design  leaders.  These  are  valid  for  all 
three  types  of  product-focused  organization,  and  are  restated  here  with  some  modifications.  The  effective  product 
design  leader: 

•  Has  responsibility  that  is  broad  in  scope  (for  which  he  or  she  has  the  requisite  broad  knowledge)  and 
endures  over  the  entire  duration  of  the  development  project 

•  Has  responsibility  for  specifications,  product  concept,  costs,  and  schedule 

•  Has  responsibility  for  ensuring  that  the  product  concept  is  accurately  translated  into  technical  detail 

•  Has  frequent  and  direct  communications  with  IPT  people  at  the  working  level 

•  Maintains  direct  contact  with  customers 

•  Has  enough  knowledge  and  experience  in  a  variety  of  disciplines  to  communicate  effectively  with  all 
relevant  people 

•  Takes  an  active  role  in  managing  conflict;  may  initiate  conflicts  to  prevent  deviation  from  the  original 
product  concept 

•  Possesses  market  imagination,  and  the  ability  to  lead  in  discerning  the  true  voice  of  the  customer 

•  Circulates  among  IPT  people,  and  leads  in  achieving  the  winning  product  concept,  rather  than  doing 
paperwork  and  conducting  formal  meetings 

By  following  these  guidelines  and  the  other  IPPD/IPT  principles  described  above,  an  organization  can  achieve 
success  with  any  of  the  three  product-focused  modes:  heavyweight  product  design  manager,  project  execution 
team,  or  independent  IPT.  The  choice  will  often  depend  in  the  short  run  on  ease  of  implementation,  which  in  turn 
will  depend  strongly  on  the  local  culture  (that  of  the  organization,  the  project,  or  even  the  IPT). 

BB.8.4  The  Team  Is  Not  Enough.  The  formation  of  the  multifunctional  IPT  is  a  good  start,  but  teams  can  go 
wrong,  with  disastrous  results.  The  planning  for  the  Bay  of  Pigs  invasion  is  often  cited  in  the  social  psychology 
literature  as  an  example  of  groupthink,  the  downside  of  team  potential.  Although  the  planning  of  a  military 
invasion  may  seem  far  from  product  development,  the  same  things  can  go  wrong.  The  team  can  develop  a  hubris, 
a  strong  desire  to  please  each  other  and  demonstrate  their  loyalty  to  the  team,  and  a  feeling  of  omnipotence,  all  of 
which  can  lead  to  disaster.  The  social  psychologist  Ian  Morley,  who  has  studied  Design  Teams  in  collaboration 
with  the  engineering  design  leader  Stuart  Pugh,  has  found  that  groups  can  go  wrong  by  having  too  much 
confidence  and  afterward  be  unable  to  understand  what  happened  (Hosking  and  Morley,  1991). 

Morley,  very  largely  on  the  basis  of  the  work  of  Irving  Janis,  has  analyzed  the  nature  of  the  problem:  (1)  “stress 
generates  strong  need  for  affiliation  within  the  group. .  ..People  who  have  misgivings  keep  silent  and  increasingly 
give  the  benefit  of  the  doubt  to  the  emerging  group  consensus.”  (2)  The  team  members  seek  to  “avoid  the  stress 
of  actively  open  minded  thinking.”  They  tend  to  focus  on  the  popular  option,  and  use  “non-vigilant  information 
processing”  (lack  of  an  IDE)  to  downplay  the  risks  that  later  become  all  too  obvious  (Hosking  and  Morley,  1991). 
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Overcoming  the  possible  dysfunctions  of  teams  is  straightforward  but  not  easy.  Successful  teams  use  the  vigilant 
information  processing  (or  IDE)  that  is  included  within  total  quality  development.  Also,  teams  can  help 
themselves  by  simply  being  on  guard  against  problems,  to  realize  that  teams  are  not  a  panacea.  Total  quality 
development  helps  the  team  to  be  vigilant  in  processing  information,  as  will  be  described  later  in  IDE.  The 
successful  team  runs  down  a  clear  path  between  facile  consensus  on  the  one  hand  and  egocentric,  disputatious 
behavior  on  the  other. 

BB.8.5  Ten  Principles  of  Successful  Teams.  Ian  Morley  (1990)  developed  10  principles  of  teamwork  in 
doing  total  development  work: 

•  Select  cohesive  teams,  based  on  sentiments  of  mutual  liking  and  respect  for  each  other’s  expertise 

•  Bring  specialists  from  all  relevant  major  functional  areas  into  the  LPT  while  maintaining  a  systems 
engineering  perspective 

•  Ensure  a  common  vision  of  the  concurrent  process 

•  Organize  controlled  convergence  to  solutions  that  everyone  understands  and  everyone  accepts 

•  Organize  vigilant  information  processing  (an  IDE)  and  encourage  actively  open-minded  thinking 

•  Avoid  the  facile,  premature  consensus 

•  Maintain  the  best  balance  between  individual  and  group  work.  Let  individuals  do  the  things  that 
individuals  do  best  -  for  example,  the  initial  generation  of  new  concepts 

•  Use  disciplined  methods  reflecting  best  engineering  practice 

•  Use  both  formal  and  informal  communication 

•  Select  at  least  some  of  the  members  according  to  how  well  suited  they  are  to  the  specific  type  of 
development  work.  One  example  is  how  static  or  dynamic  the  concepts  underlying  the  work  are.  A 
person  who  is  proficient  in  applying  standards  to  rapidly  complete  static  designs  may  have  difficulty 
with  dynamic  conceptual  work.  The  opposite  is  also  true. 

•  Provide  principled  leadership.  The  leader  must  emphasize  the  improved  process,  making  it  visible  to 
the  team.  He  or  she  must  take  the  primary  responsibility  for  helping  to  empower  members  of  the  team. 

The  organization  and  leadership  that  were  described  earlier  on  the  multifunctional  IPT  help  to  develop  the 
successful  practice  of  these  10  principles  of  teamwork.  If  these  and  the  principles  that  were  stated  earlier  for 
IPPD  are  practiced,  then  any  of  the  three  product-focused  modes  can  be  successful-heavyweight  product  design 
manager,  project  execution  team,  or  independent  IPT. 

BB.8.6  Early  Outstanding  Successes.  Two  of  the  early,  outstanding  successes  with  basic  concurrent 
engineering  or  IPPD  in  the  United  States  were  at  Ford  and  Xerox.  At  Ford  the  development  of  the  new  Ford 
Taurus  was  done  by  Team  Taurus,  led  by  Lewis  Veraldi,  from  1980  to  1985.  The  organizational  mode  was  the 
heavyweight  product  design  manager  mode;  it  was  judged  far  more  successful  than  the  previous  lightweight 
product  manager  design  mode.  According  to  Veraldi  (1988),  “Teamwork  was  a  major  factor  in  the  success  of 
Taurus  and  Sable.  Early  and  dedicated  involvement  by  all  members  of  the  team  was  key.” 

At  Xerox  the  change  was  even  more  radical.  Implemented  by  Frank  Pipp  when  he  became  manager  of  copier 
development  and  production,  the  change  in  1982  was  to  the  independent  IPT.  This  has  been  highly  successful  in 
completing  the  development  of  the  10  series  (Marathon)  copiers,  and  in  developing  the  more  recent  50  series.  At 
Xerox,  the  independent  IPT  was  led  by  a  chief  design  engineer,  and  the  IPT  was  given  a  large  degree  of 
autonomy,  as  recounted  by  Pipp  (1990): 
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To  implement  the  concurrent  engineering  approach  a  new  position,  called  Chief  Engineer,  was  created.  The 
CHENG  was  responsible  for  taking  the  product  concept  and  the  technology,  engineering,  designing  and  testing 
the  product  before  turning  it  over  for  volume  manufacturing.  Testing  included  not  only  design  verification  tests, 
field  machine  tests,  alpha  and  beta  tests  but  also  in  their  own  pilot  facilities  the  CHENGs  were  responsible  for 
building  sufficient  pilot  and  pre-production  models  to  prove  that  the  production  process  would  meet  their  design 
intent.  This  phase  included  meeting  with  major  suppliers  to  ensure  that  they  understood  drawing  specifications 
and  could  produce  parts  on  soft  and  hard  tools  to  meet  quality  and  volume  requirements.  The  CHENG  also  was 
responsible  for  delivering  the  product  in  accordance  with  the  quality,  schedule,  and  cost  goals  contained  in  the 
business  plan  and  to  accomplish  this  following  the  formal  guidelines  contained  in  the  Xerox  Product  Delivery 
Process. 

The  next  steps  were  the  ones  that  truly  allowed  a  concurrent  engineering  or  IPPD  approach  to  work,  namely  the 
transfer  of  advanced  manufacturing  engineers,  quality  control  engineers,  QA  engineers,  procurement  specialists 
and  field  service  engineers  to  the  CHENG. 

At  the  same  time  personnel  from  departments  we  called  Shared  Resources  were  assigned  to  the  CHENG’s  team 
on  a  dotted  line  basis.  These  shared  resource  activities  included:  Industrial  Design  and  Human  Factors, 
Competitive  Analysis  Laboratory,  Software  and  Electronics  Division  and  our  Supplies  Group  which  developed 
the  necessary  toners,  developers  and  photoreceptors. 

The  Xerox  CHENG  and  the  independent  IPT  do  the  pilot  production.  Of  course,  production  operations  people  are 
seconded  into  the  IPT  for  this  purpose.  The  principle  is  that  the  CHENG  is  responsible  for  all  developmental 
problem  solving.  When  the  fully  developed  system  is  transferred  to  production  operations,  the  seconded  people 
return  along  with  some  of  the  core  IPT  people. 

BB.8.7  IPT  Pitfalls  to  Avoid.  The  independent  IPT,  as  utilized  at  Xerox,  is  clearly  very  successful,  at  least  in 
the  short  run.  In  the  long  run  there  are  potential  problems  to  guard  against:  (1)  functional  obsolescence,  (2)  weak 
organizational  learning,  (3)  stale  technology,  and  (4)  outlasting  its  usefulness.  Without  a  functional  home,  the 
core  IPT  people  may  remain  strongly  focused  on  their  product  and  gradually  fall  behind  in  functional  competence. 
Organizational  learning  is  hindered  because  each  IPT  tends  to  be  isolated;  learning  does  not  spread  easily  between 
IPTs.  The  focus  of  the  IPT  is  on  their  current  product,  not  on  developing  new  technologies.  In  summary,  the 
independent  IPT  is  susceptible  to  the  parochialism  that  was  observed  as  weakness  by  the  Massachusetts  Institute 
of  Technology  Commission  on  Industrial  Productivity. 

As  the  ship  progresses  through  different  stages  of  development,  the  IPTs  should  be  reviewed  to  ensure  they  are 
still  needed,  or  new  IPTs  need  to  be  chartered. 

One  approach  to  avoiding  these  problems  is  to  have  a  shared  resource  organization  that  is  responsible  for  the  three 
problem  areas.  This  group,  often  titled  “advanced  development”  or  some  similar  name,  has  as  its  primary  mission 
the  development  of  new  technology.  The  advanced  development  group  is  usually  functionally  organized  and  is 
charged  with  also  maintaining  the  functional  competence  of  the  IPTs.  A  companion  role  is  to  facilitate  the 
transfer  of  learning  among  the  IPTs.  These  objectives  have  been  successfully  accomplished  by  forming 
functional  users’  groups,  networks  of  advisers  or  mentors,  and  a  Design  Institute,  all  of  which  extend  across  the 
full  scope  of  technical  activities. 

No  matter  what  form  the  organization  takes,  there  will  still  be  boundaries  that  must  not  be  allowed  to  create  a 
throw-it-over-the-wall  culture.  The  modes  that  focus  on  the  product  have  been  the  most  successful.  The  product- 
oriented  IPT  using  the  concurrent  process  has  been  found  to  be  much  more  successful  than  functional  groups 
using  a  sequential  process.  The  switch  to  the  multifunctional  IPT  using  the  concurrent  process  can  be  made  in 
less  than  a  year  with  strong  leadership. 
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BB.8.8  Reinforcing  the  Teams.  The  improvements  to  cooperation  are: 

•  The  multifunctional  LPT  (described  above) 

•  Employee  involvement  and  participative  management 

•  Strategic  relationships  with  suppliers 

B B . 8 . 8 . 1  Employee  Involvement  and  Participative  Management.  The  second  aspect  of  closer  cooperation, 
reinforcing  the  multifunctional  IPT,  is  employee  involvement  and  participative  management.  The  full  talents  of 
all  people  are  utilized,  and  responsibility  is  decentralized  to  empowered  teams  in  their  local  areas  of  expertise  and 
action.  The  ultimate  form  is  layered  organizational  and  communication  networks.  Communications  occur 
horizontally  and  diagonally,  on  a  need  basis,  not  excessively  constrained  by  the  vertical  orientation  of  treelike 
organization  charts.  Sometimes  the  lament  is  heard,  “Just  tell  me  what  to  do  and  I  will  do  it.”  Often,  however, 
determining  the  right  objectives  is  the  most  difficult  part  of  the  task.  The  principle  is  that  the  people  who  have  the 
relevant  information  set  the  objectives,  unconstrained  by  any  ideology  that  says  that  objectives  should  be  set  by 
some  particular  segment  or  layer  of  the  organization.  Similarly,  communications  should  occur  in  natural  patterns 
as  required  for  effectiveness  in  doing  the  work,  unconstrained  by  the  formal  organizational  chart  or  traditional 
culture.  QCD  to  satisfy  the  customer  is  always  the  guiding  light,  and  anyone  who  can  contribute  effectively 
should  participate. 

BB.8.8. 2  Strategic  Supplier  Relatipnships.  The  third  aspect  of  closer  cooperation  is  strategic  relationships 
with  suppliers.  In  addition  to  bringing  the  organization’s  own  production  and  Fleet-support  people  upstream  to 
work  concurrently  with  the  product  design  engineers,  it  is  also  an  essential  element  of  IPPD  to  bring  in  suppliers 
to  play  a  major  role  in  the  design  of  the  new  product.  In  the  old,  serial  form  of  product  development,  suppliers 
were  usually  brought  in  very  late,  at  which  time  they  could  only  respond  to  designs  that  were  already  completed 
and  compete  with  other  potential  suppliers  primarily  on  the  basis  of  lowest  quoted  cost.  This  led  to  a  proliferation 
of  a  company’s  suppliers,  none  of  whom  were  contributing  significantly  to  the  design  of  new  products.  As  a 
result,  designs  were  often  ill  suited  to  the  capabilities  of  suppliers. 

In  many  cases  the  number  of  suppliers  has  been  reduced  substantially  -  at  Xerox,  for  example,  from  more  than 
3000  in  early  1980s  to  fewer  than  400  in  the  late  1980s.  This  enables  beneficial  strategic  relationships  with 
suppliers. 

In  his  excellent  study  of  the  interactions  of  higher-level  (more  integrative)  manufacturers  and  their  suppliers, 
Toshihiro  Nishiguchi  (1989)  observed  the  effect  of  strategic  relationships  with  suppliers  as  it  emerged  with  new 
inter-firm  practices: 

Institutionally,  there  emerged  a  range  of  new  inter-firm  practices  that  were  designed  to  ensure  the  continuous 
output  of  high-quality,  low-cost  products.  Principally,  these  practices  were  based  on  “problem  solving” 
commitments  between  customer  and  subcontractor.  Examples  include  joint  price  determination  based  on 
objective  value  analysis  (VA),  joint  design  based  on  value  engineering  (VE),  the  “target  cost”  (or  “cost  planning”) 
method  of  product  development,  “profit  sharing”  rules,  subcontractor  proposals,  “black  box”  design,  “resident 
engineers,”  subcontractor  “grading,”  QA  through  “self-certified”  subcontractors,  and  just-in-time  (JIT)  delivery 
circumscribed  by  “bonus-penalty”  programs.  Along  with  these  institutional  changes,  the  main  purchasing 
function  of  the  customer  shifted  from  downstream  price  negotiation  to  the  assessment  of  subcontractor 
performance  and  the  coordination  of  various  intra-  and  inter-firm  functions. 

The  most  important  outcome  from  this  evolution  of  subcontracting  in  Japanese  manufacturing  was  a 
transformation  in  the  underlying  logic  of  contractual  relations.  The  basis  for  these  relationships  shifted  from  the 
notion  of  classical  exploitation  onto  a  new  view  of  collaborative  manufacturing,  in  the  sense  that  both  purchasers 
and  subcontractors  came  to  benefit,  under  newly  established  rules,  from  the  synergistic  effects  of  an  orientation  to 
bilateral  problem-solving. 
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In  his  comparative  study  of  electronics  suppliers  in  the  United  Kingdom  and  in  Japan,  Hishiguchi  (1989) 
observed: 

Japanese  subcontractors  also  noted  their  customers’  readiness  to  help  improve  product  quality  and  reduce  costs. 
Subsequent  case  studies,  of  Hitachi’s  subcontractor  improvement  programs  and  of  the  interesting  interactions 
between  British  subcontractors  and  their  Japanese  “transplant”  customers  in  the  United  Kingdom,  then  indicated 
an  important  conclusion.  Japanese  subcontracting  relations  have  institutional  attributes  that  promote  continuous 
improvement  in  quality  and  cost  reduction  through  “problem-solving”  oriented  commitments  between  customer 
and  subcontractor.  This  contrasted  with  the  “bargaining”  orientation  of  United  Kingdom  subcontracting  relations, 
which  tended  to  produce  adverse  effects. 

Although  this  was  a  comparison  between  the  United  Kingdom  and  Japan,  it  does  not  appear  to  be  primarily  a 
result  of  culture.  The  distinction  is  of  the  new-model  strategic  relationships  with  suppliers  versus  the  traditional 
arms-length  relationships. 

The  principle  is  simple:  make  the  suppliers  members  of  the  IPT.  There  are  two  impediments  to  implementation: 
(1)  collocation  is  difficult,  if  not  impossible;  and  (2)  residues  of  traditional  practices  may  linger  -  for  example,  the 
supplier  participates  in  the  design  but  then  does  not  receive  the  production  business.  The  second  problem  is 
straightforward  to  solve.  A  strategic  relationship  means  that  the  supplier  will  receive  the  production  business. 
Usually  there  is  a  long-term  (several  years)  contract  that  provides  guidance  and  an  infrastructure  for  the  specific 
purchases. 

BB.8.9  LPD  17  Experience.  The  DD&C  SOW  specified  that  an  IPPD  team  approach  be  used.  The 
management  structure  is  notionally  shown  in  Figure  BB-1. 


TEAM  17  NOTIONAL  IPPD 
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Figure  BB-1.  Team  17  Notional  IPPD  Approach 
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The  IPPD  team  consists  of  co-located  government/contractor  personnel.  Co-located  means  sharing  the  same 
floor,  walls,  and  overhead  with  no  intervening  walls.  The  IPPD  team  was  to  be  composed  of  persons  possessing 
the  appropriate  disciplines,  specialties,  and  functions  from  both  government  and  contractor  organizations  and  was 
to  include  subcontractor/vendor  representation.  Major  subcontractors ’/vendors’  participation  was  to  be  addressed 
in  the  IPPD  Team  Plan.  Participation  of  other  than  major  subcontractors/vendors  was  to  be  addressed  in  the  IMP. 
The  contractor  was  to  select  its  team  members,  making  certain  they  possess  the  requisite  knowledge  and 
experience  in  key  functional  areas.  The  team  members  were  delegated  the  responsibility,  authority,  and 
accountability  for  decision-making  and  management  actions  necessary  for  successful  performance  of  the 
Contract.  (No  member  of  the  IPPD  team  was  authorized  to  change  the  scope  of  the  Contract  other  than  the 
Procuring  Contracting  Officer  (PCO)  assigned  to  the  team.) 

The  contractor  was  to  apply  a  multi-functional  IPPD  team  approach  to  the  integrated,  concurrent  development  of 
the  products  and  the  associated  processes  applicable  to  the  Detail  Design,  ship  systems  integration,  construction, 
testing,  logistics  and  life  cycle  planning  support  of  the  LPD  17  and  in  performance  of  all  other  efforts  required  by 
the  Contract.  The  IPPD  team  was  to  operate  in  an  environment  that  allows  for  verification  of  product  and 
processes  as  they  evolve. 

The  IPPD  team  was  to  interact  in  accordance  with  Contract  requirements,  the  approved  IPPD  Plan,  the  Integrated 
Management  Plan  (IMP),  and  the  Master  Integrated  Resource  and  Work  Schedule  (MIRWS).  The  IMP  and  the 
MIRWS  were  to  be  maintained  as  part  of  the  Integrated  Product  Data  Environment.  This  is  an  information 
capability  which  implements,  through  phases,  the  integration  of  a  product  model  database  with  support  and 
execution  data,  in  order  to  satisfy  the  data  and  usage  requirements  of  both  the  government  and  contractor.  The 
IDE  provides  the  capability  to  concurrently  develop,  capture,  and  re-use  data  in  electronic  form. 

The  contractor  was  to  provide  the  management  effort  necessary  to  ensure  effective  cost,  schedule,  and  technical 
performance  under  the  Contract.  The  contractor  was  to  identify  methods  to  be  used  to  fully  integrate  major 
subcontractors/vendors  to  provide  overall  direction  and  guidance,  track  progress  and  status,  and  integrate  products 
and  services  provided  by  major  subcontractors/vendors’  with  the  products  and  services  provided  by  the  Full 
Service  Contractor  (FSC)  personnel. 

The  contractor  was  to  provide  the  members  of  the  IPPD  team  with  visibility  into  the  Detail  Design,  ship  systems 
integration,  construction,  testing,  logistics  and  life  cycle  support  planning  effort.  The  contractor  was  to  identify 
problems  and  potential  problems  that  could  adversely  impact  ship  performance,  cost,  and/or  delivery  schedule 
accompanied  by  proposed  solutions. 

The  government  was  to  co-locate  its  members  of  the  IPPD  team  at  a  mutually  agreed  upon  contractor  site  to 
participate  in  the  LPD  17  government/contractor  IPPD  team. 

The  government/contractor  IPPD  team  was  to  monitor  the  contractor’s  QA  activities  to  verify  conformance  with 
the  approved  Quality  Program  of  the  IMP. 

No  actions  of  the  IPPD  team  were  to  relieve  the  contractor  of  the  responsibility  to  perform  all  contract 
requirements. 

Facility /Support  for  IPPD  Team.  The  contractor  was  to  provide  all  office  space,  office  furniture,  office 
equipments  (phone,  computer  network  interconnectivity,  computer  workstations,  software  applications,  Video 
Tele -Conferencing,  facsimile  machine,  photocopy  machine,  etc.)  and  parking  facilities  identified  in  the 
contractor’s  approved  IPPD  Plan. 
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IPPD  Team  Training.  The  contractor  was  to  provide  IPPD  training  to  the  government/contractor  IPPD  team. 

The  team  training  was  to  commence  within  20  days  after  contract  award.  The  training  was  to  address,  at  the 
minimum,  the  following  topics: 

•  Development  of  IPPD  team  Goals/Objectives 

•  Development  of  IPPD  team  tools  and  metrics 

•  Development  of  IPPD  Core  Team  Worksite  layout 

•  Development  of  IPPD  team  rules  of  behavior  and 

•  Mapping  of  the  key  processes 

BB.9  COLLOCATION. 

Computers  are  tantalizing.  Enthusiasts  have  suggested  that  the  need  for  collocation  can  be  eliminated  by  the  use 
of  electronic  networks.  However,  this  seems  to  overlook  the  psychological  advantages  of  face-to-face 
collaboration.  Electronic  systems  may  ameliorate  the  advantages  of  collocation  in  the  future,  but  much 
development  is  still  needed.  Today,  physical  collocation  continues  to  have  great  advantages. 

A  related  problem  is  the  splitting  of  the  IPT  itself  between  two  major  sites.  For  example,  the  system  engineering 
and  electromechanical  design  may  be  in  New  York,  and  the  electronic  and  software  development  in  California. 

To  make  this  work  successfully,  the  chief  design  engineer  spends  much  time  on  a  frequent  basis  at  both  sites. 

Also,  the  other  enablers  of  collaborative  work  that  were  mentioned-meetings,  temporary  collocation,  and 
computers-are  fully  used. 

In  1982,  when  Xerox  switched  to  the  independent  IPT,  the  people  were  scattered  at  various  sites  in  the  Rochester, 
New  York  area.  Great  effort  was  made  to  collocate  the  teams.  This  facilitated  the  informal  communications  that 
greatly  improved  the  effectiveness  of  the  IPT. 

Strategic  relationships  with  suppliers  are  a  great  extension  of  the  multifunctional  IPT.  They  are  an  essential 
element  of  IPPD. 

Why  Collocation  Works.  It  is  easy  to  get  enthusiastic  about  the  great  improvements  in  team  communications  that 
technology  has  brought  us.  However,  this  enthusiasm  should  not  blind  us  to  a  fundamental  truth  of  product 
development.  Collocation  works.  It  consistently  produces  astonishing  improvements  in  team  performance. 
Everyone  who  has  ever  experienced  a  collocated  team  understands  this.  Those  lacking  this  experience  have  many 
interesting  theories  about  why  collocation  shouldn’t  matter.  But,  why  does  collocation  have  such  a  dramatic 
effect?  In  real  collocation,  where  team  members  are  located  within  50  feet  of  one  another,  teams  function 
differently  than  when  the  same  people  are  connected  by  electronic  communications.  Let’s  examine  some  of  these 
differences. 

First,  collocated  teams  are  rich  in  face-to-face  interactions.  Such  interactions  provide  enormous  non-verbal 
information,  the  very  information  that  conveys  most  of  the  emotional  content  of  a  message.  Facial  expressions, 
shifts  in  posture,  and  gestures  speak  volumes.  They  are  rarely  under  conscious  control,  making  them  highly 
reliable  indicators.  Unfortunately,  we  tend  to  underestimate  their  importance  because  we  react  subconsciously, 
not  consciously,  to  their  messages. 

Second,  collocated  teams  are  rich  in  verbal  rather  than  textual  communications.  Verbal  communications  convey 
an  order  of  magnitude  more  information  than  text.  Intonation,  speech  volume,  and  hesitations  convey  information 
that  is  never  present  in  written  text.  It  is  no  accident  that  teenagers  who  spend  most  of  the  time  communicating  in 
the  textual  environment  of  Internet  chat  rooms  often  lack  competencies  in  face-to-face  communications  with  their 
peers.  Verbal  communication  consists  of  much  more  than  its  textual  content. 
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Third,  collocated  teams  are  rich  in  real-time,  interactive,  communications.  This  real-time  interactivity  is  critical 
to  clarifying  and  smoothing  communications.  A  poor  choice  of  words  produces  an  instant  response,  and  an 
immediate  opportunity  for  damage  control.  Time  lags  deprive  us  of  the  feedback  that  allows  us  to  sense  the 
effectiveness  of  our  communications. 

Fourth,  collocated  teams  are  rich  in  accidental  task-oriented  communications.  Overheard  conversations  and 
accidental  interactions  provide  a  rich  flow  of  information  that  is  fundamentally  different  from  the  deliberate 
communications  of  a  dispersed  team.  These  accidental  communications  act  as  a  parallel  channel  to  deliberate 
formal  communications.  Team  members  are  confident  that  they  understand  what  is  going  on,  and  the  fidelity  of 
formal  communications  is  preserved. 

Fifth,  collocation  increases  interdependency.  This  is  important  because  the  more  times  you  must  depend  on 
others,  the  more  calibrated  you  become  to  their  behavior,  attitudes,  and  values.  A  branch  of  psychology  called 
social  expectancy  theory  suggests  that  the  ability  to  accurately  predict  the  behavior  of  other  group  members  is 
essential  to  group  productivity.  The  fabric  to  trust  is  woven  from  the  threads  of  many  small  interactions. 

Sixth,  collocated  teams  are  rich  in  non-task-oriented,  interpersonal,  communications.  Team  members  inevitably 
learn  about  the  families,  hobbies,  values,  and  lives  of  their  teammates.  With  this  knowledge  comes  an  important 
shift  in  attitude.  As  we  begin  to  see  teammates  as  real,  complex,  human  beings,  instead  of  as  stick  figures,  we 
perceive  their  behaviors  differently.  We  are  much  more  prone  to  make  negative  judgments  on  the  behavior  of 
outsiders  than  insiders.  S  uch  judgments  lead  to  negative  behaviors  that  can  easily  spiral  into  conflict. 

Seventh,  collocation  increases  team  cohesion.  For  many  psychological  reasons  we  are  more  likely  to  share 
values,  attitudes,  and  beliefs  of  people  with  whom  we  interact  intensely.  This  alignment  leads  to  motivation, 
acceptance  of  team  goals,  and  mutual  support.  Team  cohesion  is  always  highest  on  collocated  teams. 

Finally,  collocated  teams  reduce  waste.  For  example,  collocated  teams  are  often  so  in  tune  with  each  other  that 
they  don’t  even  bother  to  hold  meetings.  “Why  should  we  gather  in  a  conference  room  doing  presentations  for 
each  other  when  there  is  real  work  to  do?”  The  high-quality  communications  created  by  collocation  quickly 
truncate  unproductive  activities. 

So,  there  really  is  much  more  to  collocation  than  mere  ease  of  communication.  Certainly  every  product  developer 
must  master  the  art  of  managing  a  team  that  cannot  be  collocated.  However,  don’t  let  this  capability  delude  you 
into  underestimating  the  extraordinary  power  of  collocation.  It  remains  an  irreplaceable  tool  in  any  product 
developer’s  toolkit. 
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APPENDIX  CC 

DESIGN  TEAM  ASSESSMENT 

Ship  Design  Workforce  Metrics 


Have  done  ship  design 

Have  actually  done  it  all  the  way  through  the  design  process 

Record  of  on-time  performance  producing  a  Contract  Design/shipbuilding 
technical  package 

Have  done  a  variety  of  ship  designs 

Have  worked  with  different  types  of  engineers  from  a  range  of  organizations 

Have  produced  designs  for  a  range  of  different  ship  types 

Have  documented  ship  design  procedures  and  processes 

Have  a  process  for  passing  on  corporate  memory  of  experience  to  younger 
engineers 

Number  of  designs  of  different  ship  types  have  actually  been  built 

Understanding  of  inter-relationships  of  technical  areas  and  stakeholder 
organizations 

Distribution  of  workforce  across  generations 

Number  and  types  of  ship  design  tools  available  to  engineers 

Many  of  design  team  members  have  worked  together  before 

Ability  to  use  high  fidelity  design  software  effectively 

Ability  to  anticipate  problems  and  communicate  effectively  to  non-engineers 

Years  of  actual  design  experience 

High  technical  competence 

Understanding  of  maritime  history 

Matrix  of  skill  areas  required,  who  has  them,  and  to  what  degree  of  robustness 

Have  senior  people  who  have  done  the  work  and  a  mechanism  to  transfer  to 
others 

Feedback  on  number  and  types  of  design  errors  in  construction 

Matrix  of  organizational  and  individual  experiences  by  ship  type,  and 
mechanism  to  pass  the  experience  on  to  other  organizations  and  individuals 
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Design  Team  Readiness  Levels 


Level 

Description 

Advancement  Strategies 

1 

A  loosely-federated  team  with  ad  hoc 
processes  -  Technical  specialists  work  in  narrow 
areas  on  design  variants.  Little  process 
documentation  exists.  Retaining  needed  talent  is  a 
problem.  Team  management  has  little  formal 
leadership  training.  Workforce  administration 
activities  (performance  reviews,  etc.)  are  given 
low  priority.  Individual  team  members  have 
varying  commitment  and  understanding  of  how 
current  work  can  benefit  their  future  career 
opportunities.  Budget  and  schedule  are  often 
exceeded  to  complete  projects. 

Establish  processes  for  design  and  distribute 
documentation  of  processes  to  the  team. 

Implement  regular  drawing  board  reviews. 

Establish  periodic  training  sessions  that  focus  on 
key  areas  or  skills  that  support  design  objectives. 
Publish  metrics  regarding  design  progress. 

Train  team  members  in  Lean  Six  Sigma.  Identify 
mentorship  opportunities. 

2 

Design  Managers  assigned,  with  planning  at 
unit  level  organization  -  Teams  include 
members  from  signatures,  structures,  stability, 
survivability,  etc.  Process  is  developed  to  meet 
the  current  needs  with  Management  focus  on  unit 
level  administrative  activities.  Upper-level 
management  commits  to  continuous  improvement 
of  the  workforce  (Knowledge,  skills,  motivation, 
performance  [PCMM]). 

Improve  process  documentation  and  implement 
processes  so  that  unit  teams  and  individuals  can 
suggest  alternative  approaches.  Identify  areas 
where  improvement  is  needed  and  apply  Lean 

Six  Sigma  practices  to  achieve  some 
improvements  in  processes.  Develop 
dashboards  to  provide  easy  access  to  team  and 
unit  performance,  and  to  show  team  members 
status  of  design  development  relative  to 
objective. 

3 

Established  processes  &  practices  tie  unit 
level  processes  together  to  align  workforce 
competencies  -  The  team’s  overarching  process 
is  "open”  and  easily  modified  for  use  on  any  part 
of  the  project.  The  purpose  of  the  process  and 
practices  framework  is  to  facilitate  the 
development  of  the  workforce  and  give  guidelines 
for  unit  level  team  interactions,  thereby  allowing 
the  teams  to  function  with  more  decision-making 
authority  &  effectiveness. 

Review  performance  data  and  continue  LSS 
process  improvement  efforts.  Provide  feedback 
to  demonstrate  how  process  improvements  have 
benefited  the  team.  Apply  design  strategies  such 
as  set-based  design  to  explore  broader  range  of 
alternatives  for  given  amount  of  time.  As  team 
awareness  and  responsiveness  improves,  seek 
greater  autonomy  in  decision-making.  Expand 
dashboard  use,  increasing  level  of  detail  and 
visibility  of  performance  metrics. 

4 

Effective  overarching  process  with  metrics  to 
quantify  team’s  ability  -  The  team  includes  the 
proper,  skilled  people  and  the  system  in  which 
they  operate  is  defined  and  understood.  Unit  level 
teams  perform  tasks  autonomously  with  results 
that  upper-level  management  can  trust.  Progress 
and  performance  are  measured. 

Expand  training  activities  to  include  other  project 
teams  that  will  benefit  from  or  could  contribute  to 
team  skills.  Seek  interns  and  entry  level  talent 
and  provide  mentorship  at  all  levels.  Develop 
succession  strategies.  Expand  planning  horizon 
to  integrate  with  organizational  needs; 
proactively  seek  to  learn  from  other  programs. 

5 

Mature  Team  -  Team  skill  requirements  are 
known  and  the  right  talent  is  available.  Team 
members  have  worked  together  to  produce  and 
manage  designs  through  milestone  B  to  Critical 
Design  Review  (CDR)  in  the  past.  Processes  are 
documented.  The  team  follows  a  living  process 
and  continually  revises  and  refines  it  to  improve 
results. 

Export  processes  and  skills  to  other  programs. 
Publish  technical  papers  and  proactively 
collaborate  with  other  programs,  including  those 
outside  the  parent  organization.  Review 
performance  metrics  and  rigorously  seek 
improvements.  Define  core  value  stream, 
prioritize  improvement  needs,  and  conduct  rapid 
improvement  events  to  address  needs. 
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APPENDIX  DD 

FINANCIAL  PLANNING  AND  EXECUTION 

Budget  development,  defense,  and  execution  are  among  an  SDM’s  most  important  functions.  Without  budget  the 
SDM  cannot  perform.  Securing  excessive  funding  or  failing  to  obligate  and  expend  in  a  timely  fashion,  however, 
is  a  sure  way  to  lose  credibility.  The  DWOs  are  responsible  for  securing  funding  for  the  SIM  and  their  TWH 
pyramid.  The  funding  can  be  a  combination  of  project  or  Sponsor  funding.  The  demand  signal  and  funding  will 
be  established  yearly  in  the  AEA. 

SDMs  should  develop  and  fully  document  the  rationale  for  their  budget  requests  early.  They  should  define  the 
linkage  between  the  performance  requirements  and  required  engineering  support.  Budgeting  should  include 
negotiations  with  and  development  of  written  tasking  for  all  participants,  including  SEA  05  Group  Heads  on 
mission  funded  and  reimbursable  support.  The  budget  must  consider  applicable  design  approval  and  certification 
requirements.  SDMs  are  intended  to  have  full  control  over  resources  approved  by  the  Program  Manager.  Given 
that,  the  SDM  has  overall  responsibility  for  delivering  a  fully  integrated,  technically  acceptable  product. 

SDMs  should  establish  procedures  for  the  timely  receipt  of  near  current  obligation  and  expenditure  data  and  for 
tracking  that  data.  Ship  design  phases  up  through  Contract  Design  are  usually  funded  through  RDT&E  money. 
Technically,  this  money  has  a  two-year  life  span  for  obligation,  meaning  it  can  theoretically  be  carried  over  for 
almost  one  whole  year  beyond  its  appropriation  year.  In  practical  terms,  however,  the  OMB  has  established 
obligation  and  expenditure  guidelines  on  a  monthly  basis  that  require  virtually  all  the  money  to  be  obligated 
within  the  first  year.  More  than  half  the  expenditures  need  to  be  made  during  the  first  year.  Therefore,  holding  a 
“reserve”  beyond  April  or  so  places  that  money  in  jeopardy  of  being  taken  by  the  Program  Office  for  other, 
emergent  needs. 

Money  that  is  carried  over  is  handled  differently  between  government  organizations,  such  as  NSWC  laboratories 
and  design  agents.  The  former  have  been  under  increasing  scrutiny  for  carrying  over  funds  and  will  likely  not  be 
able  to  expend  any  funds  beyond  the  first  quarter  (i.e.,  December)  of  the  second  year,  even  if  they  still  have  some 
on  the  books.  Private  industry  should  still  be  able  to  expend  the  funds,  however.  In  either  case,  careful  attention 
should  be  paid  to  project  “carry  over”  funds  by  early  summer  and  money  shifted  if  necessary.  Carryover  of  at 
least  one  month  and  up  to  two  months  is  desirable  to  prevent  a  work  stoppage  at  the  beginning  of  the  fiscal  year 
since  it  takes  about  that  long  to  process  tasking  for  the  new  money. 

SDMs  should  be  careful  to  budget  considering  the  possibility  of  an  extension  of  the  AoA  or  a  requirement  to 
continue  feasibility  studies  long  after  completion  of  the  AoA. 
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Financial  Planning  Tasks 

The  following  tasks  represent  the  minimum  effort  required  by  the  SDM  in  financial  planning: 

•  Analyze  customer  program  requirements  and  develop  a  proposed  budget 

•  Negotiate  budget  with  SEMs  at  the  WTA/SOW  level 

•  Verify  that  receiving  organizations  can  provide  the  needed  quality  of  support 

•  Analyze  risk  and  allocate  funds  for  risk  mitigation  early 

•  Negotiate  project  budget  with  Program  Office  or  other  source  as  part  of  the  AEA.  (The  SDM  should 
remember  that  SDMs  are  always  in  competition  for  funds,  so  have  a  good  justification  for  every  dollar 
requested.) 

•  Establish  project  financial  management  procedures.  (It  is  especially  important  to  institute  monthly 
reporting  from  Navy  labs  to  track  actual  expenditures.  They  have  had  a  poor  record  in  the  past, 
resulting  in  either  shortfalls  or  large  carryovers  at  the  end  of  the  fiscal  year.) 

•  Develop  current  year  quarterly  obligation  profiles  based  on  analysis  of  rate  of  fund  expenditure 
projections  at  the  WTA/SOW,  task  group,  and  project  level 

•  Identify,  prepare,  and  initiate  funding  and  tasking  documents  critical  to  the  proposed  ship  design 
schedule 

The  final  budget  is  documented  with  an  obligation  plan,  which  is  sent  to  the  Program  Office  or  other  source. 
Please  see  Appendix  EE  for  an  example  of  an  obligation  plan. 

Factors  Affecting  Design  Cost 

There  are  no  standard  cost  estimates  for  accomplishing  design  of  a  certain  type  of  ship.  The  cost  of  each  must  be 
developed  on  the  basis  of  the  specific  design  effort  needed  to  accomplish  the  task  at  hand.  This  is  not  to  say  that 
there  is  no  relevance  of  one  design  experience  to  another.  The  costs  of  designing  two  similar  auxiliary  ships  will 
have  relationships  that  would  not  be  applicable  to  the  cost  of  designing  a  destroyer. 

Historical  cost  data  for  many  designs  conducted  since  1970  and  up  to  1990  are  contained  in  the  Ship  Design 
Project  Histories  Book,  commonly  referred  to  as  the  “Red  Book.”  Copies  of  it  may  be  found  in  the  SEA  05D 
library.  Sample  budgets  from  recent  design  efforts  are  also  available  from  the  division  directors  and  other  SDMs. 
Ship  design  annual  reports  will  contain  the  historical  data.  Remember  that  older  design  efforts  used  more  in- 
house  NAVSEA  personnel  and  far  fewer  reimbursable  laboratory  personnel  than  is  the  typical  case  today. 

With  this  database,  the  estimate  for  the  overall  design  process  should  be  developed,  taking  into  account  the  scope 
of  the  effort  required  by  the  Program  Office,  particularly  efforts  which  go  beyond  SEA  05  ’s  direct  responsibility. 
Estimated  costs  should  be  escalated  in  accordance  with  escalation  rates  provided  by  SEA  05C.  The  significant 
Shipbuilder  overhead  rates  should  be  considered. 
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The  amount  of  man-days  expended  during  a  particular  design  effort  is  a  reflection  of  several  characteristics  of  the 
design  problem  itself,  the  personnel,  and  their  organization.  Consideration  must  be  given  to: 

•  Duration  of  the  design  process 

•  The  design  strategy  for  use  of  contractors  and  Shipbuilders 

•  The  newness  of  the  design  concept  or  technology 

•  Program  risks 

•  The  ability  to  reuse  design  documentation  and  design  features  from  previous  designs 

•  The  amount  of  knowledge  available  from  earlier  design  efforts 

•  The  confidence  in  building  directly  on  available  knowledge 

•  Ship  manpower  and  enhancement  of  shipboard  human  performance,  safety,  survivability,  and  quality 
of  life 

•  The  number  of  organizational  interfaces  requiring  concurrence  and  coordination 

•  The  personnel  available  and  their  experience 

•  Engineering  data  availability 

•  Dependence  on  developmental  systems  and  technologies 

•  The  level  of  design  and  consequent  level  of  detail  required  both  to  perform  the  engineering  and  to 
adequately  define  the  output 

As  the  design  proceeds  from  the  feasibility  studies  phase  to  Contract  Design,  the  cost  estimation  process  becomes 
less  and  less  dependent  on  historical  comparisons  and  more  and  more  on  specific  activities  flowing  from  the 
individual  design. 
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Funded  Activities  Supporting  Ship  Design 

The  following  activities  are  considered  to  be  essential  and  integral  to  the  ship  design  process.  They  are  to  be 
funded  as  elements  of  the  ship  design: 

•  Preparation  of  the  Engineering  Management  Plan  and  other  design  planning  documentation 

•  Preparation  of  feasibility  study,  Pre-Preliminary  Design,  Preliminary  Design,  and  Contract  Design 
reports 

•  SDM  and  SEM  management  support 

•  Whole  ship  design  engineering  analysis,  e.g.,  system  safety;  survivability;  ILS;  RAM;  T&E;  manning; 
supportability;  HSI;  electromagnetic  environmental  effects,  and  hull  signatures 

•  System  level  human  performance  requirements  analysis,  including  top  down  requirements  analysis 

•  Systems  level  architecture  engineering  analysis 

•  Final  technical  reviews  at  completion  of  each  design  phase  and  as  otherwise  required 

•  Funding  of  Navy  laboratories  for  model  tests  and  other  work 

•  Design  feedback  data  acquisition  and  analysis 

•  Development  of  design  deliverables 

•  Maintenance  of  an  IDE 

•  Ship  specification  development  and  comment  adjudication 

•  Review  of  contractor  technical  deliverables 

•  Design  tools  and  modeling  and  simulation 

•  Requirements  traceability 

•  Risk  mitigation  efforts 

•  Preparation  of  annual  reports 

•  Travel 

•  Design  site  operations 

•  ABS  involvement  as  appropriate  for  classed  ships 

•  Cost  team 

•  Industry  requests  for  information 

•  Design  decision  memoranda 

•  Model  tests 
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APPENDIX  EE 

SAMPLE  OBLIGATION  PLAN 


EE-1  /(EE-2  blank) 


S9800-AC-MAN-01 0 


APPENDIX  FF 
SCHEDULE  MANAGEMENT 

Project  schedules  developed  by  the  SDM  must  be  consistent  with  the  schedules  put  forth  by  the  Program  Office. 
Based  on  the  acquisition  strategy,  the  SDM  should  establish  preliminary  project  schedules  for  the  conduct  of  the 
intervening  design  effort.  Ideally,  SEMs  will  prepare  WT A/SOW  schedules  using  the  preliminary  project 
schedule  as  guidance.  The  SDM  then  integrates  these,  revises  the  Preliminary  Design  schedules,  and  negotiates 
differences  and  conflicts  with  both  the  Program  Office  and  the  SEMs.  The  project  schedule  will  contain  many 
important  milestones.  They  indicate  when  tasks  must  be  completed  to  ensure  successful  accomplishments  that 
provide  measurable  and  demonstrable  evidence  of  progress  of  the  design  toward  the  project  goals.  Milestones 
are,  therefore,  not  isolated  events  and  their  interrelationship  should  be  described  in  the  management  plan.  They 
provide  both  visibility  and  control  points  for  the  project  and  should  be  selected  accordingly.  Thus,  they  should  be 
selected  so  that  their  accomplishment  will  be  useful  for  gauging  the  progress  of  the  project  both  technically  and 
financially.  By  definition,  there  will  be  a  minimum  number  of  milestones.  They  may  take  any  form  such  as  a 
meeting,  design  review,  or  document  issue  so  long  as  the  event,  if  successful,  signifies  meaningful  design 
progress.  See  the  Virtual  SYSCOM  System  Engineering  Technical  Review  Handbook  NAVSEAINST  5000.9 
(hyperlink). 

Interdependencies  and  predecessor  relationships  should  be  incorporated  into  the  schedule.  This  will  identify  the 
“critical  path,”  the  sequence  of  interdependent  events  that  establishes  the  current  completion  date.  For  most 
programs,  DD&C  contracting  depends  on  conduct  of  a  Navy  Program  Decision  Meeting  (for  ACAT  IC,  II,  III, 

IV)  or  DAB  (for  ACAT  ID)  which  is  dependent,  in  turn,  on  approval  of  all  planning  documentation,  including  the 
performance,  cost,  and  schedule  thresholds  and  objectives  of  the  acquisition  program  baseline.  Approval  of  the 
baseline  depends,  in  turn,  on  agreement  on  the  current  POM,  approval  of  the  acquisition  strategy,  and  approval  of 
the  CDD  or  CPD.  Agreement  on  the  POM  turns  on  completion  and  reconciliation  of  the  independent  cost 
estimate  and  program  life  cycle  cost  estimate.  Completion  of  these  estimates  depends  on  approval  of  the  CDD  or 
CPD.  Their  finalization  is  required  before  completion  of  the  design  effort,  preferably  well  before  the  end  of 
Preliminary  Design. 

In  organizing  the  schedule,  attention  should  be  given  to  the  frequency  of  the  design  reviews.  No  specific 
formulas  can  be  set  down  to  guarantee  the  benefits  resulting  from  judicious  planning  and  scheduling  of  design 
reviews.  Each  design  project  will  have  a  unique  design  review  schedule.  Clearly,  though,  in  structuring  the 
schedule,  design  reviews  should  be  planned  to  occur  with  a  frequency  sufficient  to  preclude  large  man-day 
expenditures  occurring  without  the  SDM’s  participation.  More  important,  design  reviews  should  be  scheduled  to 
occur  at  the  points  in  time  when  the  decisions  are  being  molded,  still  fluid,  and  amenable  to  modification  with 
minimum  disruption  to  the  remaining  schedule. 

The  schedule  is  therefore  not  just  a  depiction  of  a  collection  of  independently  established  and  planned  activities 
and  events.  Properly  developed,  it  provides  a  representation  of  the  coordinated  and  integrated  activity  of  a  variety 
of  organizations.  Further,  it  becomes  a  means  to  assure  the  SDM  of  adequate  visibility  of  the  progress  of  the 
design. 
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A  useful  design  schedule  must  go  to  a  significant  level  of  detail  to  identify  critical  items  and  must  include  at  least 
the  following: 

•  Iterative  total  ship  design  cycles  (e.g.,  design  baseline  issues).  (Typically,  the  engineering  effort  for 
each  cycle  will  span  four  to  six  weeks.  An  additional  two  to  three  weeks  should  be  added  to  each  cycle 
to  allow  for  proper  documentation,  briefing,  and  cleanup.) 

•  Key  documentation  deliveries  to  support  program  milestones  and  deliveries  to  outside  activities  (e.g., 
TEMP,  Cost  Analysis  Requirements  Description  [CARD]) 

•  Documentation  to  support  internal  Program  Office  acquisition  activities  such  as  RFPs  and  source 
selections 

•  Documentation  to  support  annual  budget  submissions,  especially  for  doing  the  design  itself 

•  Design  review  schedules  (Block  out  overall  prep  times  and  major  review  dates.) 

•  Production-driven  dates  for  information  or  technology-driven  dates  for  testing  (e.g.,  what  size  engine 
should  be  tested  depends  on  ship  powering  calculations) 

•  Critical  decision  dates  for  selecting  the  hull  form,  or  other  major  system  decisions 

•  Key  management  reporting  dates 

The  importance  of  a  sound  initial  schedule  cannot  be  overstated.  Change  inevitably  will  occur  and  disrupt  the 
most  careful  planning.  However,  a  well  thought  out  schedule  should  provide  contingency  room  in  risk  areas 
wherever  practical.  A  comprehensive  knowledge  of  milestone  interdependencies  will  be  invaluable  in 
restructuring  planning  when  such  needs  arise  during  the  actual  design  activity. 

Whatever  systems  are  used  to  display  milestones  and  other  events,  they  should  be  simple  to  administer,  visible  to 
all  concerned,  and  flexible  enough  to  accommodate  the  inevitable  changes  from  planning  to  reality. 

The  IWS  DWO  will  develop  an  Integrated  Master  Schedule  (see  Appendix  GG)  that  will  include  all  major 
reviews  including  gate  reviews.  This  IMS  will  be  used  to  estimate  the  demand  signal  for  a  specific  fiscal  year  as 
well  as  a  planning  tool  for  SIM  and  TWH  to  develop  their  work  schedule  for  a  specific  year. 
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APPENDIX  GG 
IWS-IMS  REQUIREMENTS 


1 .  All  ACAT,  NON  ACAT  funded  programs  or  funded  Pre-Systems  Acquisition  programs  shall  report  all 
systems  Engineering  and  Acquisition  program  events. 

2.  Each  program  needs  to  indicate  program  status  (active/non-active)  and  indicate  ACAT  category 
(approved  or  proposed)  Example:  SSDS  (Blue  character  will  indicate  is  a  non-ACAT  program,  Black  is 
an  ACAT  program) 

Post  MLS  C  -  “Indicates  the  Program  status” 

3.  The  schedule  shall  include  the  program  Technical  Reviews  and  Acquisition  Milestones  following  events 
including  but  not  limited  to:  ITR,ASR,SRR,PDR,IBR,CDR,TRR,FRR,OTRR,SVR,FCA,PRR,PCA,ISR, 
all  gate  reviews,  SSSTRPAVSERB,MRA,PCD,IPCD,  Certification  meetings,  program  review,  major  test 
and  or  qualification  events,  QER,  contract  awards  (i.e.,  .LRIP),  demonstrations. 


4.  The  following  legend  will  be  use  to  indicate  the  type  of  event: 


I  i.  A  Technical  AN  T 

Legend: /A,  Review  {J 


O' 


Oc 


Major  Event  For  Information 


5.  Update  to  the  schedule  should  be  monthly  if  no  changes  are  required  an  email  should  indicated  it. 

6.  For  schedule  format  see  the  following  figure. 
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APPENDIX  HH 

DESIGN  STRUCTURE  MATRIX  AND  DESIGN  PROCESS  MODELING 

HH.1  OVERVIEW. 


A  Design  Structure  Matrix  (DSM)  and  Multi  Domain  Matrix  compactly  represents  the  relationships  between 
design  activities.  Figure  4-5  shows  an  example  of  a  Multi  Domain  Matrix.  In  this  representation,  each  of  the 
rows  corresponds  to  a  Design  Activity,  and  each  of  the  columns  a  Design  Variable.  The  numbered  diagonal 
represents  that  Design  activity  for  row  n  produces  as  output  variable  the  design  variable  in  column  n.  A  dot  in  a 
cell  indicates  that  the  associated  design  activity  for  the  row  takes  as  input  the  design  variable  corresponding  to  the 
column  of  the  dot.  By  sequencing  the  design  activities  in  the  order  of  execution,  much  can  be  learned.  Dots 
below  the  diagonal  indicate  variables  that  have  been  produced  by  previous  design  activities.  Dots  above  the 
diagonal  indicate  variables  that  are  needed  by  a  design  activity,  but  are  not  scheduled  to  be  produced  until  the 
future.  The  value  of  the  variable  must  be  assumed,  a  “cluster”  of  activities  as  shown  in  Figure  HH-2  must  be 
solved  simultaneously,  or  the  design  activities  must  be  re-sequenced.  Determining  the  optimal  ordering  of  design 
activities  is  relatively  easily  accomplished  using  well  known  matrix  operations. 

Another  insight  that  can  be  easily  observed  is  shown  by  variables  1  and  2  of  Figure  HH-2.  These  two  variables 
do  not  depend  on  each  other  in  any  way  and  could  be  solved  in  parallel. 
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Figure  HH-1.  Multi  Domain  Example 

As  the  level  of  fidelity  of  design  activities  increase  with  time,  the  number  of  relationships  between  design 
activities  as  well  as  the  total  number  of  design  activities  is  expected  to  increase.  The  design  process  should  not  be 
expected  to  be  constant  over  the  evolution  of  a  design.  The  matrix  provides  valuable  insight  on  how  the  design 
process  must  evolve  as  fidelity  increases. 

While  Figure  HH-2  shows  the  relationships  between  design  activities  and  design  variables  as  “dots”,  these  dots 
can  represent  data  structures  defining  the  fidelity  and  data  format  used  in  the  data  transaction.  Likewise,  the 
diagonal  “numbered  boxes”  could  represent  the  data  structure  defining  the  characteristics  of  the  design  activity. 
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HH.2  ACTIVITY  MODELING. 


There  are  many  ways  to  model  a  ship/system  design  activity  for  integration.  A  modeling  technique  that  has 
proven  useful  over  time  is  based  on  the  IDEFO  definition  of  a  function.  As  shown  in  Figure  HH-3,  a  Design 
Activity  interacts  with  external  activities  via  Inputs,  Outputs,  Controls,  and  Mechanisms.  Inputs  are  those  data 
elements  needed  to  perform  the  design  activity.  Outputs  are  those  data  elements  that  are  produced  by  the  design 
activity.  Controls  impact  the  manner  in  which  the  design  activity  is  performed,  and  Mechanisms  are  the  resources 
needed  to  perform  the  design  activity. 


Controls 


Input 


Design 

Activity 

1 

Output 


Mechanisms 


Figure  HH-3.  IDEFO  Activity  Model 


In  executing  a  process,  much  of  the  focus  is  on  the  interaction  of  the  design  activities  via  the  Input  and  Output 
Variables.  In  constructing  the  matrix  from  a  set  of  design  activities  however,  the  controls  become  equally 
important;  the  controls  govern  the  list  of  input  variables,  the  properties  of  the  Input  Variables,  and  the  properties 
of  the  Output  Variables  associated  with  the  Design  Activity. 

The  primary  Control  Variable  used  in  Design  Activity  modeling  is  the  requisite  fidelity  of  the  Input  and  Output 
Variables.  The  level  of  fidelity  of  the  Output  Variable  may  govern  which  design  tool  is  used  for  that  part  of  the 
design  process;  it  may  also  require  a  different  set  of  Input  Variables  of  varying  levels  of  fidelity. 

Other  Control  Variables  include  input  variable  data  formats,  output  variable  format,  type  of  hull,  major  hull 
material,  and  mission  type. 

Defining  a  Design  Activity  in  this  manner  can  result  in  multiple  sets  of  design  tools  being  employed  depending  on 
the  Control  Variables. 
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This  dynamic  nature  of  the  number  and  type  of  input  variables  based  on  the  value  of  a  Control  Variable 
differentiates  ship  design  processes  from  classical  IDEFO  process  modeling.  Consequently,  a  different  technique 
for  interconnecting  design  activity  models  is  needed.  Instead  of  IDEFO  process  modeling,  using  a  matrix  for 
describing  the  inter-relationships  of  design  activities  is  more  appropriate. 

More  than  one  design  activity  can  share  the  same  Output  Variable.  For  example,  one  Design  Activity  that  fulfills 
the  “Hull  Resistance  Analysis”  function  may  be  based  on  model  testing  while  another  may  be  based  on  detailed 
computational  fluid  dynamics.  The  two  Design  Activities  could  differ  in  the  required  input  variables  and  would 
likely  result  in  a  differing  set  of  Mechanisms. 

HH.3  DESIGN  PROCESS  MODELING. 


Figure  HH-4  shows  a  simplified  process  model.  In  addition  to  the  core  matrix  shown  in  Figure  4-1,  it  also  shows 
dependencies  on  assumptions,  as  well  as  the  dependency  of  output  activities  on  the  design  variables  and 
assumptions.  Note  that  all  the  Outputs  are  independent  of  each  other  and  all  of  the  assumptions  are  independent 
of  each  other.  Also  note  that  while  the  matrix  is  inherently  square,  the  number  of  assumptions  does  not  have  to 
equal  the  number  of  outputs,  hence  the  Design  Process  Model  is  not  required  to  be  “square.” 
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Figure  HH-4.  Design  Process  Model 


HH.4  ANALYSIS. 


This  is  a  powerful  tool  for  identifying  integration  issues  within  a  given  design  process. 

When  using  the  design  spiral,  common  practice  is  to  ignore  any  dependencies  above  the  diagonal  of  the  matrix. 
Instead  the  results  from  the  previous  iteration  are  assumed  for  the  design  activity.  In  this  way,  the  design  spiral 
ensures  a  lower  triangular  matrix  for  a  given  design  iteration.  This  will  generally  work  if  the  dependencies  above 
the  diagonal  are  weak  compared  to  other  dependencies. 

In  certain  cases,  it  will  be  impossible  to  eliminate  a  strong  dependency  from  above  the  diagonal.  In  this  case, 
convergence  may  be  faster  if  this  internal  “cluster”  of  Design  Activities  is  solved  as  a  spiral  within  the  overall 
ship  design  spiral. 
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Alternatively,  the  Design  Activities  and  the  variables  they  produce  may  be  redefined  to  eliminate  dependencies 
above  the  diagonal.  One  way  is  to  redefine  each  design  activity  within  a  “cluster”  to  produce  a  response  surface 
instead  of  a  point  solution.  After  all  of  the  response  surfaces  from  the  Design  Activities  in  the  cluster  are 
produced,  an  additional  design  activity  is  employed  to  find  the  intersections  of  the  response  surfaces  which  would 
constitute  the  design  point  for  that  iteration. 

Clusters  of  Design  Activities  should  also  be  the  focal  point  of  efforts  to  automate  data  exchange,  to  conduct 
process  improvement  efforts  in  the  conduct  of  the  design  activities,  as  well  as  to  establish  the  boundaries  for  IPTs. 

In  Set-Based-Design,  the  matrix  can  be  effectively  used  to  define  the  required  dimensions  of  the  “sets”  or 
response  surfaces  provided  by  each  discipline.  At  each  process  gate  however,  the  level  of  fidelity  of  the  design 
must  improve.  This  implies  that  additional  Design  Activities  and  dependencies  may  be  required.  In  planning  a 
Set -Based  Design  iteration,  one  has  to  understand  these  ever-increasing  dependencies  to  ensure  the  domain 
specific  design  and  analysis  produces  the  requisite  response  surfaces  (design  variables)  of  the  right  dimensions 
(dependencies).  The  end  result  is  that  in  execution  a  Set-Based  Design  matrix  may  have  additional  integration 
activities,  but  the  matrix  will  be  lower  triangular. 

HH.5  DESIGN  PROCESS  MODELING. 

Efforts  have  also  begun  to  model  the  ship  design  processes  using  PLEXUS  and  other  software  tools.  This  will 
provide  an  initial  template  for  new  ship  design  programs  to  use  to  define,  model,  and  optimize  schedule,  resource 
availability,  and  resource  requirements  for  each  design  phase. 
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APPENDIX  II 

SAMPLE  STATEMENT  OF  WORK 


SOW  TITLE 

SOW  B3  -  Systems  Engineering 

RESOURCES 

NAVSEA  - 

Level  of  Effort  (LOE)  Support  - 
Government  Activities  - 
Other  - 
OBJECTIVE 

Provide  support  to  the  Ship  Design  Team  in  the  evaluation  of  alternative  design  features,  for  the  Packing  of  key 
parameters,  and  assisting  in  design  integration. 

PRELIMINARY  DESIGN  TASK  DESCRIPTION 

1 .  Conduct  engineering  and  cost  evaluations  and  trade-off  studies  for  design  alternatives  on  the  basis  of  a  total 
ship  system  perspective. 

CONTRACT  DESIGN  TASK  DESCRIPTION 

1 .  Periodically  update  and  issue  the  Parameter  Allocation  Report  which  tracks  trends  in  weight,  KG,  electric 
power,  HVAC  load,  area/volume,  manning,  speed,  and  endurance. 

2.  Evaluate  the  impact  of  concepts  proposed  to  reduce  weight  and  cost  and  recommend  actions.  Total  ship 
impacts  of  individual  features  or  combinations  of  features  will  be  systematically  analyzed  to  define  primary  and 
secondary  impacts  in  a  consistent  manner.  Special  studies  will  be  undertaken  as  directed  to  define  the 
performance,  cost,  and  weight  impacts  of  new  technologies  and  alternative  features. 

3.  Assist  in  the  evaluation  of  concepts  proposed  to  enhance  producibility.  Emphasis  will  be  on  identifying  the 
impact  on  ship  performance,  size,  and  weight,  so  that  the  cost  benefits  postulated  for  the  concept  can  be 
considered  in  conjunction  with  changes  to  technical  considerations  and  possible  secondary  impacts. 

4.  When  directed  by  the  SDM,  evaluate  the  impacts  of  major  technical  issues  with  total  ship  impact  in  an  “off¬ 
line”  environment,  and  prepare  input  necessary  for  the  decision-making  process  to  the  SDM. 

5.  Conduct  special  studies  in  support  of  mainstream  efforts  on  an  as  needed  basis. 

DESIGN  ACTIVITY  MODEL 

1.  DESIGN  ACTIVITY 

Conduct  total  ship  analysis  to  include  development  of  the  Parameter  Allocation  Report,  impact  studies  of 
weight  reduction,  cost  reduction  and  producibility  enhancement  proposals  as  well  as  other  major  total  ship 
technical  issues. 

2.  INPUTS 

All  design  variables  associated  with  the  ship  configuration 
All  system  analysis  reports 

3.  OUTPUTS 

Parameter  Allocation  Report  and  Study  Reports 
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4.  CONSTRAINTS 

Reports  shall  be  accurate  enough  to  make  good  decisions 

5.  MECHANISMS 

Tools 

Personnel  required  per  study 
Time  required  per  study 

PRELIMINARY  DESIGN  PRODUCTS/SCHEDULE 

Para.  No.  Title  Issue  Date 

1 .  Preliminary  Design  Technical  History  Input  Final 

CONTRACT  DESIGN  PRODUCTS/SCHEDULE 


Para.  No. 

Title 

Issue 

Date 

1. 

Parameter  Allocation  Report 

Monthly 

2. 

Various  Special  Study  Reports 

As  Req’d 

3. 

Contract  Design  Technical  History  Input 

Final 
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APPENDIX  JJ 

ANNUAL  EXECUTION  AGREEMENT  TEMPLATE  FOR  SDM 


JJ.1  PROGRAM  CONTEXT. 

Provide  a  short  narrative  description  of  where  the  program  is  in  the  stream  of  ship  design  and  construction 
activities.  Indicate  who  has  the  lead  for  design  development  efforts,  and  provide  a  general  description  of  how  the 
Navy  Design  Team  manages  risk  and  provides  engineering  support  for  the  program.  If  the  program  is  in-line 
construction,  indicate  which  hulls  are  still  being  actively  worked  by  the  Design  Team.  Include  in  this  section  a 
listing  of  significant  technical  and  program  milestones  or  evolutions  that  are  either  ongoing,  or  will  occur  during 
the  coming  year. 

JJ.2  NATURE  OF  REQUIRED  ENGINEERING  SUPPORT. 

Provide  a  detailed  listing  of  engineering  products  and  services  that  must  be  produced  by  the  Navy  Design  Team. 
The  listing  should  include  an  estimate  of  the  average  manhour  work  content  associated  with  each  category  of 
items,  as  well  as  an  estimate  of  the  anticipated  volume  of  items  over  the  coming  year.  Where  practical,  specific 
categories  of  items  should  be  ranked  relative  to  risk,  to  facilitate  discussions  of  funding  priorities  in  cases  where 
all  necessary  work  cannot  be  funded  due  to  funding  cuts.  Significant  separate  risk  reduction  efforts  (e.g.,  conduct 
of  a  scale  model  test  program)  should  be  shown  as  separate  activities  (i.e.,  apart  from  the  core  Design  Team)  for 
ease  of  understanding.  Adequate  focused  Risk  Management  and  Systems  Safety  efforts  are  a  necessary  part  of  all 
AEAs. 

JJ.3  REQUIRED  CYCLE  TIMES. 

Turnaround  times  for  each  category  of  items  shall  be  stated,  and  it  should  be  noted  how,  when,  and  by  whom  due 
dates  for  individual  items  are  assigned.  Where  needed,  a  procedure  for  arranging  tailored  due  dates  for  more 
complex  items  should  be  included  in  the  AEA. 

JJ.4  RESOURCE  AND  FUNDING  ALLOCATIONS. 

A  tabular  listing  of  funding  commitments  (by  performing  activity)  shall  be  included  for  approval  by  the  Program 
Manager.  Mission  funded  assets  being  made  available  to  the  program  shall  be  shown  as  well.  Separate  risk 
reduction  efforts  should  be  shown  as  separately  identified  line  items,  with  those  costs  being  segregated  from  the 
overall  Design  Team  budget.  This  section  of  the  AEA  should  state  the  SDM’s  presumptions  relative  to  the  level 
of  risk  inherent  in  the  agreed  upon  funding.  If  negotiations  will  not  support  a  minimum  level  of  government 
effort  required  to  support  certification  of  the  ship  by  the  warranted  technical  authorities,  the  matter  should  be 
elevated  to  CSE  Ships  and  PEO  Ships  for  resolution. 

JJ.5  METRICS  AND  TEAM  PERFORMANCE. 

The  SDM/SIM/TWH  is  responsible  for  delivering  on  the  commitment  made  in  the  AEA  that  he  or  she  signs  along 
with  the  Program  Manager.  The  SDM/SIM/TWH  shall  manage  the  resources  allocated  in  the  AEA  as  a  business, 
including  the  Design  Team  budget.  The  SDM  will  monitor  obligations  of  funds,  expenditures  of  funds,  and 
performance  at  both  Warfare  Centers  and  LOE  contractors.  A  control  point  for  work  flow  and  measuring 
throughput  will  be  established  by  the  SDM/SIM/TWH.  Metrics  required  by  the  Program  and  CSE  will  be  tracked 
and  reported  by  the  SDM  on  a  continuing  basis. 
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APPENDIX  KK 
DESIGN  ENVIRONMENT 

A  smoothly  functioning  design  environment  can  facilitate  the  design  process  and  allow  participants  to  focus  their 
energies  on  design  challenges.  Conversely,  a  poorly  functioning  design  environment  can  drive  up  costs,  disrupt 
schedules,  and  cause  the  design  to  fail.  Design  environment  issues  rarely  have  the  appeal  of  ship  technical  issues 
to  the  SDM.  Nevertheless,  the  design  environment  and  the  collection  of  design  tools  that  will  be  applied  to  the 
program  deserve  the  SDM’s  careful  attention. 

A  variety  of  acronyms  are  used  to  describe  design  environments.  These  include: 

•  Integrated  Data  Environment 

•  Integrated  Design  Environment 

•  Integrated  Digital  Environment 

•  Integrated  Product  Development  Environment  (IPDE) 

•  Integrated  Product  Data  Environment  (IPDE) 

•  Integrated  Data  Environment/Smart  Product  Model  (IDE/SPM) 

•  Integrated  Data  and  Product  Model  Environment  (IDPME) 

The  variety  of  acronyms  illustrates  two  points  important  to  the  SDM.  First,  people  have  widely  varying  concepts 
of  the  functionality  and  scope  of  the  design  environment.  The  SDM  must  be  careful  to  understand  what 
individuals  mean  to  imply  when  they  use  these  terms.  Second,  design  environments  tend  to  be  recreated  for  each 
individual  program.  While  many  elements  of  the  design  environment  will  pre-exist,  the  program,  changes  in 
teaming  arrangements,  business  relationships,  information  technology,  etc.  will  usually  cause  participants  to 
“improve”  the  process  used  on  the  previous  program. 

There  are  two  major  groups  of  design  environment  functions  of  interest  to  the  SDM.  These  are  discussed  in 
following  sections.  The  first  is  to  document  management  and  design  process  control.  The  second  is  ship  design 
development.  Throughout  the  remainder  of  this  section,  the  acronym  “IDE”  denotes  a  design  environment 
fulfilling  both  these  functions. 

Planning  for  an  IDE  should  start  very  early  in  the  life  of  a  project.  Initially,  the  number  of  people  with  access  to 
the  IDE  will  be  relatively  limited  because  of  the  small  size  of  the  Design  Team.  As  time  progresses,  the  IDE  may 
include  thousands  of  participants.  SDMs  should  work  closely  with  the  Program  Office  to  ensure  adequate 
resources  are  assigned  to  implement  the  IDE. 

IDE  development  must  be  at  least  one  phase  ahead  of  design  development.  Parallel  development  of  an  IDE  and 
the  ship  design  it  supports  is  a  recipe  for  disaster.  The  SDM  must  oversee  an  IDE  development  and/or 
implementation  effort  that  provides  adequate  scope,  capacity,  and  function  for  the  next  phase.  He  must  insist  on 
readiness  reviews  and  testing  to  ensure  capability. 

IDE 

An  IDE  is  a  collection  of  business  processes,  computer  systems,  and  associated  services,  which  house  the  product 
model  data,  and  enable  people  to  work  in  concert  towards  common  business  goals  throughout  the  life  cycle  of  a 
product. 

A  common  drawback  of  these  environments  is  their  proprietary  (closed)  architecture,  inhibiting  the  flexibility  to 
reconfigure  and  adapt  to  changing  program  requirements  without  significant,  costly  customization.  Despite  all  of 
the  effort  in  building  and  maintaining  these  IDEs  there  are  still  many  deficiencies.  Two  major  issues  to  be 
addressed  when  designing  an  IDE  is  how  to  efficiently  manage  changes  and  how  to  share  product  information 
with  other  Navy  activities  and  Shipbuilders. 
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It  is  usually  not  possible  for  a  single  project  to  specify  the  hardware  and  software  solutions  for  the  multiple 
organizations  that  participate  in  a  typical  complex  project.  Generally,  the  hardware  and  software  procurement 
decisions  for  an  organization  are  made  independent  of  any  one  specific  project.  Concentrating  on  specifying 
interface  standards  will  likely  be  a  more  successful  strategy.  The  interface  standards  to  support  a  given  program 
may  not  be  completely  compatible  with  the  hardware  or  software  of  a  given  organization.  If  the  infrastructure  is 
not  compatible,  the  organization  may  need  to  invest  additional  resources  to  gain  the  requisite  level  of 
interoperability. 

Ideally,  a  given  project  should  not  have  to  invest  in  developing  the  hardware  and  software  infrastructure  to 
implement  an  IDE.  In  reality  however,  projects  may  have  to  provide  funding  to  organizations  to  enable 
interoperability.  On  the  other  hand,  projects  should  be  expected  to  expend  resources  to  develop  documented 
business  processes,  and  to  actively  manage  the  information  within  the  IDE. 


Figure  KK-1.  IDE  Notional  Architecture 
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Figure  KK-1  notionally  depicts  the  core  capabilities  of  an  IDE  along  with  requirements  for  Interoperability  and 
Data  Exchange  between  the  major  applications  that  make  up  an  IDE.  The  dashed  line  illustrates  the  boundary  of 
the  IDE  specification  in  the  scope  of  an  overall  IDE.  This  notional  model  shows  the  applications  supporting  the 
major  shipbuilding  and  support  functions  as  vertical  columns.  These  vertical  applications  are  different  for  each 
implementation  of  an  IDE;  some  IDEs  will  not  have  all  the  applications  shown  or  may  include  additional 
applications.  The  IDE  core  capabilities  support  the  vertical  applications  and  provide  management  of  and  control 
access  to  the  product  model  data.  The  functional  requirements  for  an  IDE  include: 

•  Communication  -  For  most  projects,  this  consists  of  email.  The  posting  of  documents  such  that  others 
can  retrieve  it  is  another  form  of  communication. 

•  Collaboration  -  Collaboration  is  the  cooperative  action  of  two  or  more  individuals  resulting  in  a  total 
effect  that  is  greater  than  the  sum  of  the  individual  efforts.  This  synergistic  effect  can  be  achieved 
through  appropriate  business  rules  that  take  advantage  of  the  IDE  software  and  hardware  infrastructure. 

•  Data  Storage  -  The  ability  to  save  project  information  for  future  use  is  key  to  having  the  information 
available  to  participants. 

•  Data  Retrieval  -  Similarly,  once  data  is  within  the  IDE,  participants  must  have  the  ability  to  retrieve 
the  data  for  their  use. 

•  Configuration  Control  -  Configuration  Control  is  necessary  to  ensure  that  participants  are  using  the 
right  data  in  the  accomplishment  of  their  jobs. 

•  Search  Capability  -  It’s  not  only  important  to  be  able  to  retrieve  data,  but  it  is  also  important  for 
participants  to  quickly  find  all  relevant  data  to  assist  in  the  accomplishment  of  their  jobs. 

Key  IDE  processes  needed  to  implement  these  functions  include: 

•  Access  Control  -  Access  Control  ensures  that  those  with  a  need  to  know  information  have  access  to 
the  appropriate  information. 

•  Information  Security  -  Information  Security  ensures  those  without  a  need  to  know  don’t  have  access 
to  sensitive  information. 

•  Business  Process  Definition  -  Defines  how  participants  interact  with  one  another  and  with  the 
information  within  the  IDE. 

•  Information  Structure  Development  -  The  information  structure  defines  who  is  responsible  for 
managing  different  types  of  information  from  creation  through  disposal,  how  that  information  is  stored 
within  the  IDE,  and  how  access  to  the  information  is  determined. 

•  Interface  Specification  -  Defines  the  interface  requirements  between  hardware,  software,  and  people 
necessary  to  implement  an  IDE. 

•  Life  Cycle  Management  of  Information  -  Life  Cycle  Management  of  Information  is  the  day-to-day 
implementation  of  the  Information  Structure  using  the  Business  Process 

•  Training  -  An  IDE  can  only  be  effective  if  all  participants  understand  how  to  properly  employ  it. 
Training  is  key  to  ensuring  a  successful  IDE. 
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Summary  of  SDM  IDE  Concerns 

Are  IDE  planning,  development,  and  implementation  verifiably  adequate  and  on  track  for  the  next  design  phase? 

Are  systems  and  procedures  in  place  to  support  IDE  functions  and  processes  across  the  Design  Team,  which  may 
be  geographically  and  corporately  distributed  and  use  products  from  different  software  vendors? 

Among  the  CAD,  etc.,  systems  in  use  for  DEFINITION  development  on  the  design  project,  how  are  hull  shaping 
and  subdivision  (i.e.,  molded  DEFINITION),  structural  arrangement,  component  placement,  and  distributive  system 
arrangements  kept  consistent?  What  is  the  authoritative  source  of  configuration/geometry  data  and  how  are  the 
others  kept  in  synch  as  the  design  evolves? 

What  characteristics  and  performance  of  the  ship  are  the  Design  Team  trying  to  predict  with  computer  tools  (i.e., 
visualization,  spreadsheets,  computer-assisted  engineering,  simulation,  etc.)?  These  should  align  with  check 
elements  and  TWHs.  What  tools  will  the  Design  Team  use?  What  is  the  process  or  system  for  confirming 
alignment  between  the  analysis  results  and  the  configuration  and  geometric  data  defining  the  current  design? 

What  software  or  process  will  the  Design  Team  use  to  relate  document  images,  such  as  technical  manuals, 
reports,  trade-off  studies,  etc.,  to  configuration  data  and  analysis  results? 

What  software  or  process  will  the  Design  Team  use  to  relate  requirements  and  specifications  to  the  configuration 
elements  that  satisfy  them  and  the  analysis  results,  simulations,  and  tests  that  prove  their  satisfaction? 
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APPENDIX  LL 

ENGINEERING  MANAGEMENT  PLAN 

This  appendix  is  intended  to  provide  guidance  for  preparation  of  the  Engineering  Management  Plan.  The 
Engineering  Management  Plan  should  be  an  unclassified  document.  Necessary  classified  information  can  be 
provided  under  separate  cover.  The  Engineering  Management  Plan  should  be  approved  by  the  Division  Director. 

Prior  to  New  Construction  DD&C.  the  SUPSHIP  CHENG  and  SDM  will  jointly  author  the  EMP  to  further 
elaborate  and  define  roles  and  responsibilities  tailored  to  the  specific  program.  The  EMP  will  include  (among 
many  other  details)  that: 

•  The  SDM  will  lead  all  design  reviews. 

•  The  SUPSHIP  CHENG  and  SDM  will  jointly  accomplish  the  technical  review/disposition  of  Test 
problems  (including  Test  Procedures  and  actual  testing)  with  accountability  split  as  described  in 
NAVSEAINST  5400.95E. 

•  The  SDM  and  SUPSHIP  CHENG  will  co-author  a  “technical  readiness  for  trials”  memo.  This  will  be  a 
serialized  memo  from  the  Chief  Systems  Engineer  (Ships)  to  the  Program  Manager. 

•  The  SUPSHIP  CHENG  and  SDM  will  jointly  accomplish  providing  the  technical 
review/recommendations  during  the  Program  Office  disposition  of  Trial  Cards  with  accountability  split 
as  described  above. 

•  The  SUPSHIP  CHENG  has  the  lead  for  technical  approval  of  all  specifications  for  post -delivery  work, 
but  will  rely  on  the  SDM  for  design  related  issues. 

•  A  formal  turnover  of  technical  authority  at  the  OWLD  (usually  end  of  warranty  period)  from  the 
SUPSHIP  CHENG  and  SDM  to  the  In-Service  SDM  and  RMC/Shipyard  CHENG  (for  USN  ships)  or 
to  MSC  (for  USNS  ships).  The  turnover  documentation  will  provide  full  disclosure  and  transparency 
of  engineering  decisions  made  and  outstanding  items/non-conformances  remaining  at  transfer.  For 
MSC  ships,  MSC  assumes  operational  technical  authority  after  delivery,  and  all  aspects  of  technical 
authority  at  OWLD. 

For  in-service  ships,  the  SDM  and  RMC  CHENG  will  not  generally  author  or  execute  an  EMP.  An  exception  to 
this  may  occur  during  major  overhauls  where  the  scope  of  alteration  to  the  ship  systems  requires  further 
refinement  of  roles  and  responsibilities  associated  with  Technical  Authority. 

The  Engineering  Management  Plan  should  include  the  following  elements: 

1.0  Introduction  -  This  element  is  intended  to  describe  the  content,  status,  and  use  of  the  management  plan.  The 
following  items  should  be  included  (as  applicable). 

(a)  General  Description  of  plan  content  and  use. 

(b)  Provisions  for  plan  revision. 

2.0  Design  Strategy  -  Define  the  use  of  headquarters  personnel,  field  activities,  contractor  support,  complete 
design  farm-out,  or  other  means  of  accomplishing  the  design  phases.  Discuss  the  type  of  design,  Navy  Design  or 
Contractor  Design. 

3.0  Background 

(a)  General  description  of  acquisition  program  including  overarching  schedule. 

(b)  Brief  summary  of  work  accomplished  in  previous  phase. 

(c)  Brief  statement  of  work  planned  for  the  next  phase. 
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4.0  Organization  -  This  section  shall  briefly  describe: 

(a)  Organizational  relationships  to  Program  Office,  SUPSHIP,  ABS  and  any  other  government/industry 
members  of  the  Program  Office  team.  The  interface  with  the  participating  SYSCOMs  will  be 
specifically  discussed.  Responsibilities  and  interfaces  of  Design  Team  members  will  be  discussed. 

(b)  Project  team  organization  from  SDM  to  SEMs  to  TLs  to  TWHs  including  responsibilities. 

(c)  Project  directory  with  names,  organizations,  area  of  responsibilities,  and  telephone  numbers  of 
participating  NAVSEA  personnel  and  those  from  other  activities. 

(d)  In-house  manpower  projections. 

(e)  Identify  purpose  and  membership  of  IPTs,  Working  Groups,  and  special  ad-hoc  groups,  such  as 
Shipbuilder’s  Review  Team. 

(f)  Who  will  sign  Ship  Specifications,  drawings,  and  other  design  products. 

5.0  Technical  Approach  -  This  section  shall  describe  the  technical  environment  of  the  project: 

(a)  Project  Objective  and  Primary  Constraints 

(b)  Design  Scope  and  General  Methodology 

(c)  Design  Products 
6.0  Task  Planning  and  Budget 

7.0  Design  Activities  and  Technical  Control 

(a)  Architectures,  Interface  Control,  and  Work  Breakdown  Structure 

(b)  Requirements  Definition,  CONOPS,  Design  Reference  Mission,  Specification,  and  Technical  Baseline 
Definition 

(c)  Technical  Performance  Measures  and  Metrics 

(d)  Design  Budgets 

(e)  Design  Considerations 

(f)  Technical  Certifications 

(g)  Integrated  Master  Schedule 

(h)  Reporting  and  Technical  Reviews 

(i)  Engineering  and  Integration  Risk  Management 

(j)  Design  Team  Meetings,  Action  Items,  Issues,  Design  Decision,  Specification  Change/Configuration 

Management  Processes,  and  the  Integrated  Digital  Environment 
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APPENDIX  MM 
RISK  MANAGEMENT 

One  of  the  SDM’s/SIM’s  primary  roles  is  to  support  and  enable  an  effective  risk  management  process.  This 
program  addresses  programmatic  risks  and  system  safety  risks. 

A  programmatic  risk  is  a  measure  of  future  uncertainties  in  achieving  program  performance  goals  and  objectives 
within  defined  cost,  schedule,  and  performance  constraints.  Programmatic  risk  addresses  the  potential  variation  in 
the  planned  approach  and  its  expected  outcome.  Programmatic  risks  have  three  components: 

•  A  future  root  cause  (yet  to  happen),  which,  if  eliminated  or  corrected,  would  prevent  a  potential 
consequence  from  occurring 

•  A  probability  (or  likelihood)  assessed  at  the  present  time  of  that  future  root  cause  occurring,  and 

•  The  consequence  (or  effect)  of  that  future  occurrence 

A  system  safety  risk  is  a  combined  measure  of  both  severity  and  probability  that  a  hazard  that  could  result  in  a 
mishap.  A  hazard  is  threat  of  harm  to  an  asset  having  value  one  would  wish  to  protect.  Each  system  safety  risk 
involves  a  brief  narrative  description  of  a  potential  mishap  attributable  to  the  hazard.  A  hazard  description 
contains  three  elements  that  express  the  threat: 

•  A  source,  an  activity,  or  a  condition  that  serves  as  the  root 

•  The  mechanism,  a  means  by  which  the  source  can  bring  about  the  harm,  and 

•  An  outcome,  the  harm  itself  that  might  be  suffered 
Programmatic  risk  management  programs  include: 

•  Identification  and  submission  of  risk  by  team  members 

•  Assessment  of  likelihood  and  consequences,  prioritization,  and  assignment 

•  Development  and  implementation  of  effective  risk  mitigation  plans 

•  Tracking  and  reporting 

Acquisition  programs  have  come  to  use  very  similar  processes  and  documentation.  Figures  MM-1,  MM-2,  MM-3 
and  MM-4  illustrate  typical  risk  process  elements,  a  scheme  for  assessment  of  risk  severity,  and  a  risk  summary 
worksheet.  A  variety  of  supporting  software  is  available.  The  SDM  should  coordinate  with  the  Program  Office 
in  software  selection.  Figure  MM-5  summarizes  residual  risk  approval  requirements. 

A  formal  risk  management  process  may  be  integrated  into  the  normal  program  action  item  identification  and 
tracking  process  with  little  additional  effort.  Often,  however,  programs  either  make  the  mistake  of  overdoing  it 
by  establishing  a  large  and  manpower-consuming  risk  management  organization  or,  conversely,  not  progressing 
beyond  the  PowerPoint  level. 

The  SDM/SIM  must  ensure  that  the  Design  Team  actively  participates  to  make  certain  that  technical  risks  are 
accurately  described  and  appropriate  mitigation  plans  are  developed. 

The  SDM/SIM  should  be  alert  to  the  effects  of  compound  integration  risks.  For  example,  program  establishment 
of  a  severe  crew  size  limit  can  ripple  through  a  design,  generating  technical  risk  for  a  number  of  areas. 

From  an  SDM/SIM  perspective,  identifying  and  rating  risks  is  important  at  the  total  system  level  rather  than  the 
subsystem  level.  For  example,  a  communications  system  antenna  may  assume  requirements  that  are  considered 
high-risk  to  achieve,  but  from  a  total  system  viewpoint  there  may  be  multiple  other  communication  channels  at 
different  frequencies  that  can  get  the  same  information  across  so  that,  overall,  the  risk  of  not  communicating  is 
much  less. 
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What  Can  Go  Wrong? 

•  Proposed  changes 

-  Staffing 

-  Process 

-  Design 

-  Supplier 

•  Transition  to  production 
checklists 

•  Test  failures 

•  Expectation  Shortfalls 

•  Failure  To  Perform 

•  Negative  trends 

•  Issues  list 

•  ...And  more 


How  Big  Is  the  Risk? 

•  Likelihood 

•  Possible 
consequences 

•  Categories 

-Cost 

-  Schedule 

-  Technical 

•  Identify  the  risk  level 
from  the  5x5  risk  grid 


How  Are  Things  Going? 

•  Communicate  risks  to  all 
affected  parties 

•  Monitor  risk  plans 

•  Review  regular  status 
updates 


How  Can  You  Reduce 

the  Risk? 

•  A  void  by  eliminating  the 
risk  cause  and/or 
consequence 

•  Control  the  cause  or 
consequence 

•  Transfer  the  risk 

•  Assume  the  risk  level  and 
continue  on  current  plan 

•  ...And  more 


Mitigation  Plan 
Implementation 


How  Can  the  Mitigation 

Plan  Be  Implemented? 

•  Determine  what  planning, 
budget,  and  requirements 
changes  are  needed 

•  Review  with  management 
and  the  customer 

•  Incorporate  the  changes 

•  Implement  the  plan 


Figure  MM-1.  Risk  Process  Elements 

An  important  consideration  in  executing  the  risk  management  process  is  the  allocation  of  resources  needed  to 
perform  the  risk  mitigation  steps  identified  in  the  plan.  Without  adequate  funding,  the  process  will  not  achieve 
the  desired  result  of  reducing  risk.  The  SDM  needs  to  aggressively  pursue  such  support  for  the  important 
technical  risks.  Further,  since  the  allocation  of  big  money  is  at  stake,  getting  the  risk  ratings  correct  is  worth  the 
investment  of  SDM  energy. 

Note  that  DoD,  as  evidenced  in  the  current  SEP  template,  now  expects  Programs  to  manage  issues  and 
opportunities  thought  a  comparable  if  not  the  same  process  as  risks. 
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■o 

o 

o 


What  Is  the  Likelihood  the  Risk  Will  Happen? 

Your  Approach  and  Processes... 

1 

Not  Likely: 

...Will  effectively  avoid  or  mitigate  this  risk  based  on 
standard  practices 

2 

Low  Likelihood: 

...Have  usually  mitigated  this  type  of  risk  with 
minimal  oversight  in  similar  cases 

3 

Likely: 

...May  mitigate  this  risk,  but  workarounds  will  be 
required 

4 

Highly  Likely: 

...Cannot  mitigate  this  risk,  but  a  different  approach 
might 

5 

Near  Certainty: 

...Cannot  mitigate  this  type  of  risk;  no  known 
processes  or  workarounds  are  available 

^7 


o 

O 


5 

4 

3 

2 

1 


—  Low 


o 

O 


Given  the  risk  is  realized,  what  would  be  the  magnitude  of  the  impact? 

Level 

Technical 

Schedule 

Cost 

1 

impac 

Minimal  or  no  impact 

: 

Minimal  or  no  impact 

Minimal  or  no 

2 

Minor  perf  shortfall, 
same  approach 
retained 

Additional  activities 
required;  able  to  mee 
key  dates 

Budget  increase  or 
t  unit  production  cost 
increase  <1% 

3 

Mod  perf  shortfall, 
but  workarounds 
available 

Minor  schedule  slip; 
will  miss  need  date 

Budget  increase  or 
unit  production  cost 
increase  <5% 

4 

Unacceptable, 
but  workarounds 
available 

Program  critical  path 
affected 

Budget  increase  or 
unit  production  cost 
increase  <10% 

5 

Unacceptable;  no 
alternatives  exist 

Cannot  achieve  key 
program  milestone 

Budget  increase  or 
production  cost 

1  2  3  4  5 

Consequence 


Figure  MM-2.  Assessment  of  Risk  Severity  (Notional  Criteria) 


Risk  Summary  Worksheet 

Risk  Title  _  Team  _  Date 


Figure  MM-3.  Typical  Risk  Form 
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Time 

Figure  MM-4.  Risk  Waterfall  or  Burn  Down  Chart 


Level  of  Risk 

Technical  Authority:  Approves 
Analysis  of  Residual  Risk 

Programmatic  Authority:  Accepts 
Residual  Risk 

User/Fleet  Coordination 

Program: 

Acquisition 

In-Service 

High 

Systems  Command  (SYSCOM) 
Commander 

MDA  or  Assistant  Secretary  of  the 

Navy  for  Research,  Development  and 
Acquisition  (ASN(RDA)) 

Sponsor 

Type  Commander 

Moderate 

Deputy  Warranting  Officer 

Program  Executive  Officer 

Sponsor 

Type  Commander 

Low 

TWH 

PM 

Sponsor 

Type  Commander 

System  Safety: 

Acquisition 

In-Service 

High 

SYSCOM  Commander 

ASN  RDA 

Sponsor 

Type  Commander 

Serious 

Deputy  Warranting  Officer 

PEO 

Sponsor 

Type  Commander 

Medium 

TWH 

PM 

Sponsor 

Type  Commander 

Low 

TWH  or  Certificate  Holder 

PM 

Figure  MM-5.  Residual  Risk  Acceptance  Requirements 
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APPENDIX  NN 
DESIGN  REVIEW  CONTENT 

This  section  addresses  those  reviews  conducted  by  the  Navy  on  its  own  ship  designs  or  concepts,  as  well  as 
reviews  of  industry  designs  where  the  Navy  is  gauging  technical  acceptability  of  the  engineering  products  and  the 
inherent  technical  risks  involved. 

This  Appendix  provides  a  general  view  of  items  that  are  (or,  depending  upon  the  phase,  could  be)  applicable  to  all 
design  reviews  and  should  be  considered  for  inclusion  in  all  of  them.  If  any  of  the  below  factors  and  design 
topics  are  not  included  in  the  review,  there  should  be  a  good  reason  why  it  was  not  addressed  at  some  level. 
Appendix  Q  provides  SETR  entrance  and  exit  criteria  that  should  also  be  considered  in  development  of  the 
briefing. 

Major  design  review  objectives  include: 

•  Ship/System  Size  -  Confirm  that  the  ship/system  has  been  sized  properly  from  the  naval  architectural 
perspective,  including  provision  of  adequate  design  margins  and  service  life  allowances. 

•  Stability  -  Appropriate  ship/system  control,  acceptable  ship/system  dynamics,  and  adequate 
ship/system  stability  have  been  provided. 

•  Technically  Feasible  -  Confirm  that  the  ship/system  is  technically  feasible.  Ascertain  that  there  are  no 
design  conditions  that  would  preclude  arriving  at  a  technically  acceptable  ship  across  all  areas, 
including  compliance  with  applicable  design  rules. 

•  Design  Strategy  -  A  comprehensive  design  and  risk  management  strategy  has  been  developed  that  is 
executable  within  the  time  and  resources  available.  Any  base  assumptions,  both  programmatic  and 
technical,  have  been  validated  by  the  Navy  stakeholder  involved. 

•  HSI  Strategy  -  A  comprehensive  HSI  strategy  will  or  has  demonstrated  that  sufficient  crew  size  and 
skill  levels  are  successfully  matched  to  the  ship  configuration  (including  accommodations  and 
automation  features)  in  a  manner  consistent  with  prevailing  Navy  policies  such  as  mixed  gender, 
hybrid  sailor,  and  total  ship  training  architecture.  This  strategy  must  employ  functional  workload 
analysis;  identification  of  required  knowledge,  skills,  and  abilities;  and  usability  testing  of  operator 
interfaces. 

•  Safety  -  The  ship/system  and  its  crew  will  be  safe  to  operate.  Sufficient  active  and  passive 
survivability  has  been  provided,  consistent  with  program  requirements. 

•  Effectiveness  -  Mission  effectiveness  has  been  demonstrated  in  accordance  with  the  applicable 
requirements  documents  (e.g.,  CDD),  applicable  force-level  interoperability  requirements,  (e.g., 
FORCEnet  compliance),  and  higher  level  configuration  management/capability  evolution  policies  (e.g., 
open  architecture  compliance). 

•  Top-Level  Requirements  -  Confirm  that  other  non-mission  KPPs  and  ICD/CDD  requirements  have 
been  met,  such  as  speed,  endurance,  operational  availability,  and  time  on  station. 

•  Build  Strategy  -  A  coherent  build  strategy  has  been  developed,  consistent  with  lean  shipbuilding 
principles.  The  ship  is  buildable  using  the  intended  facilities  and  production  techniques. 

•  Readiness  for  Release  -  Assess  the  completeness  and  accuracy  of  the  design  and  make  a  determination 
regarding  release  outside  the  command  or  display  at  a  higher  level. 

•  Design  Approval  -  For  completed  Contract  Designs,  assess  the  design  for  the  purposes  of  design 
approval. 
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Prior  to  conducting  any  design  review,  an  agenda  should  be  issued  that  provides  an  outline  of  the  material  to  be 
discussed  in  the  review.  The  review  date  should  be  published  well  in  advance  so  that  participants  can  come 
prepared.  The  timing  should  be  progress-based  vice  calendar-based.  For  instance,  a  PDR  should  not  be 
scheduled  to  occur  at  a  time  when  it  is  clear  the  basics  of  Contract  Design  have  not  been  finished.  The  agenda 
should  specify  the  following: 

List  of  technical  efforts,  topics,  and  systems  to  be  reviewed: 

•  Objective  of  the  review,  desired  outcome,  or  decision 

•  Review  approach 

•  Requirements  and  criteria  applicable  to  material  under  review 

•  Exit  criteria  (if  applicable) 

Generally,  less  is  better.  The  primary  objective  is  to  present  the  distilled  facts  pertinent  to  the  decision  at  hand, 
vice  a  comprehensive  portrayal  of  the  depth  of  work  accomplished  in  the  design  phase.  For  government  reviews 
of  industry  designs,  the  evaluation  of  output  is  generally  intended  to  provide  a  tool  for  the  Program  Manager  to 
apply  in  influencing  both  the  industry  engineering  effort  (scope  and  strategy)  and  the  industry  products 
(engineering  deliverables  and  ship).  So,  it  is  important  to  not  only  identify  risk  gaps  and  technical  issues,  but  also 
to  present  assessments  (How  bad  is  it?)  and  constructive  recommendations  (What  should  the  Program  Manager  do 
about  it?).  Technical  authorities  also  owe  the  Program  Manager  contrasting  perspectives  on  what  issues  represent 
features  of  the  design  that  are  technically  unapprovable,  vice  those  that  could  be  made  approvable  with  additional 
effort. 

Top-Level  Outline: 

Purpose  of  the  Review 
Entrance  and  Exit  Criteria 
Overview  of  the  Program 

•  State  of  requirements  development 

•  Schedule  showing  milestones  and  key  events 

•  Primary  participants  (government  and  industry)  and  their  relationships 

•  Any  governing  top  level  direction  (e.g.,  acquisition  decision  memoranda  (ADMs)  exit  criteria  or  other 
direction  from  the  MDA) 

Overview  of  Requirements 

•  ICD 

•  CDD 

•  Other 

•  Process  for  requirements  flowdown  to  the  design  and  specifications 

Overview  of  Execution  Strategy 

•  Acquisition  Strategy 

-  Phasing  and  competition 

-  Payload  development  strategy 

-  Role  of  industry  (cooperative  or  competitive) 
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•  Design  Strategy 

-  Who  has  the  lead,  government  or  industry? 

-  Support  strategy  (warfare  centers  versus  level-of-effort  contractors) 

-  Review  and  approval  strategy 

-  Risk  management  and  risk  tracking  approach 

-  Design  decision  process  and  baseline  configuration  controls 

-  Design  philosophy,  i.e.,  priority  order  for  competing  functions  and  features  or  capacities  that  are 
desired  on  the  ship.  Conversely,  what  is  the  SDM  most  willing  to  trade-off  to  preserve  or  optimize 
functionality  higher  on  the  list? 

-  Macro  interface  control  approach 

-  Margins  utilization  policy 

Overview  of  Design 

•  CONOPS  deployment  concept 

•  Design  reference  mission 

•  State  of  total  ship  system  engineering,  the  functional  analysis,  and  requirements  flow  down  process 

•  Mission  effectiveness  analyses,  measures  of  effectiveness/performance,  and  interoperability 

•  General  arrangements  and  machinery  arrangements 

•  Design  tools  methodology,  SPM,  IDE,  and  product  data  management 

•  Ship  and  system  descriptions  (Include  aviation  and  off-board  vehicle  interfaces  where  applicable.) 

•  Margins  utilization  status  against  plan 

-  Weight/KG 

-  Electric  generating  capacity 

-  Air  conditioning  capacity 

-  Accommodations 

-  Speed/powering 

-  Area/volume/tankage 

-  Service  life  allowances  provided 

•  Status  of  critical  analyses 

-  Weight  estimate 

-  Electric  load  analysis 

-  Air  conditioning  load  analysis 

-  Vulnerability/survivability  analysis 

-  Signature  analysis 

-  Speed/power  prediction 

-  RAM  analysis 

-  HSI  analysis  -  crew  size  estimate,  workload  estimates,  training  impacts,  link  analysis,  usability 
and/or  other  human  performance  testing 

•  Status  of  hull/propulsor  model  test  results 

•  Unresolved  technical  issues 

Conclusions/Exit  Criteria 

Proposed  Next  Steps  or  Recommendations 
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Ship/System  Pricing,  performed  by  or  validated  by  SEA  05C,  should  be  available.  This  information  is  usually 
considered  in  executive  session  at  the  end. 

With  regard  to  technical  content,  there  are  a  number  of  topic  areas  that  should  be  fully  addressed,  depending  on 
design  phase.  Using  the  following  general  approach  within  each  topic  area  ensures  that  the  material  is  presented 
in  a  logical  and  consistent  manner: 

•  Configuration  Description  -  The  presentation  should  provide  a  general  description  of  the  layout  and 
functional  operation  of  the  system(s)  under  review  and  its  performance  characteristics. 

•  Design  Validation  -  Demonstrate  that  the  design  meets  requirements  (including  applicable  design 
rules)  and  will  perform  its  intended  function.  Trade-off  studies  and  other  supporting  materials  may  be 
presented  to  demonstrate  that  the  design  is  the  preferred  solution. 

•  Design  Interface  -  Demonstrate  that  all  interfaces  between  systems  and  subsystems  have  been 
recognized  and  are  controlled.  Where  appropriate,  design  budget  allocations  have  been  established. 

•  Risk  -  Principal  elements  of  risk,  risk  mitigation  efforts,  and  current  issues  being  addressed. 

The  following  is  a  typical  list  of  topics  that  should  be  covered  during  a  design  review  broken  down  by  major 
discussion  areas.  These  should  be  mapped  into  the  review  outline  in  a  fashion  that  fits  the  context  of  the 
particular  review. 

•  Total  Ship/System 

-  Ship  characteristics 

-  General  arrangements 

-  Design  margins  and  service  life  allowances 

-  Mission  capability 

-  Hull  capability 

-  Survivability 

-  Reliability,  availability,  and  maintainability 

-  Regulatory  body  compliance 

•  Ship  and  Mission  Systems 

-  Hull  structure 

-  Propulsion  plant 

-  Machinery  arrangements 

-  Electric  plant 

-  Command  and  surveillance 

-  Auxiliary  systems 

-  Outfit  and  furnishings 

-  Armament 

-  Ship  assembly  and  build  strategy 

-  Logistics  support  assumptions 

•  Integration/Engineering 

-  Mission  Systems  Integration  (including  land  based  test  sites  and  battle  force  integration)  test 
strategy 

-  System  technical  architecture 

-  Human  systems  integration 

-  Computing  plant  and  network  infrastructure 

-  Information  security  architecture 
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•  System  Safety 

•  Systems  engineering  and  program  management 

•  Requirements  traceability  analysis 

•  Risk  management 

•  Schedule  to  complete  ship  design,  construction,  and  delivery  (including  critical  path  analysis) 

•  Schedule  and  commitments  from  parallel  interdependent  payload  system  programs 

•  Configuration  management 

•  System  test  and  evaluation 

•  Definition  of  any  engineering  development  models 

•  Development  and  operational  test  and  evaluation 

•  Design  Tools 

•  Modeling  and  simulation  (including  VV& A) 

•  Test  and  evaluation  support 

•  Test  facilities 

•  Training 

-  Training  concept  and  architecture 

-  Equipment 

-  Services 

-  Facilities 

•  Status  of  data  deliverables 

•  IDE 

•  Technical  documentation,  including  design  history 

•  Engineering  data 

•  Management  data 

-  Support  data 

-  SPM 

•  Peculiar  support  equipment 

-  Test  and  measurement  equipment 

-  Support  and  handling  equipment 

-  Common  support  equipment 

•  Operational/site  activation 

-  System  assembly,  installation,  and  checkout  on  site 

-  Contractor  technical  support 

-  Site  construction 

-  Site/ship/vehicle  conversion 

•  Production/industrial  facilities 

-  Production  approach 

-  Labor  force 

-  Construction/conversion/expansion 

-  Equipment  acquisition  or  modernization 

-  Maintenance  (industrial  facilities) 
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•  Life  cycle  engineering  and  support 

-  Logistics  concept  including  Performance  Based  Logistics  (PBL)  approach 

-  Initial  spares,  outfitting,  and  repair  parts 

-  Shore  facilities/pier  facilities 

•  Affordability 

-  Cost  as  independent  variable  trade-off  studies 

-  Life  cycle  cost  estimate  (including  basis  of  estimate  and  supporting  data) 

•  Research  and  development  cost 

•  Procurement  cost 

-  NRE  (non-recurring  engineering)/Design 

-  Recurring 

•  Operating  and  support  cost 

•  Disposal  cost 

While  it  always  makes  sense  for  the  most  knowledgeable  person  to  brief  technology-specific  content,  as  a  general 
rule  the  SDM  (government  or  industry  as  appropriate)  should  be  the  primary  briefer,  particularly  for  overview, 
strategy,  and  integration  related  topics.  The  presentation  should  be  supported  by  appropriate  drawings  and 
specification  sections,  as  well  as  study  reports,  design  notebooks,  etc.  These  materials  do  not  have  to  be 
presented,  but  must  be  organized  and  available  if  needed. 

For  any  review  to  be  meaningful,  there  must  be  a  set  of  top-level  exit  criteria  against  which  the  design  may  be 
evaluated.  Each  design  review  will  have  its  own  specific  criteria.  Factors  to  consider  in  defining  these  are: 

•  Requirements:  The  design  must  meet  the  documented  requirements  of  the  program. 

•  Technical  Adequacy:  All  aspects  of  the  design  solution  must  satisfy  the  documented  technical 
standards,  be  internally  consistent,  and  interconnect  properly  with  the  other  parts  of  the  design.  The 
ability  of  the  solution  to  meet  the  requirements  must  be  validated. 

•  Risk:  The  major  areas  of  technical  risk  in  the  design  solution  must  be  identified  and  risk  mitigation 
plans  developed  that  include  provisions  for  fallback  solutions.  If  no  realistic  fallbacks  are  available, 
this  fact  must  be  stated. 

Following  the  conclusion  of  the  review,  the  results  must  be  documented  in  a  set  of  minutes.  The  minutes  need  to 
include: 

•  Identification  of  the  review  topics 

•  List  of  attendees 

•  General  assessment  of  design  progress 

•  List  of  decisions  and  directives  made 

•  List  of  action  items,  actionees,  and  due  dates  for  responding  to  action  items 

These  minutes  need  to  be  issued  in  a  timely  manner  to  all  participants  and  interested  parties.  In  the  case  of 
government  reviews  of  competitive  industry  designs,  the  distribution  may  be  restricted  to  government  recipients 
only. 
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APPENDIX  00 

DISPOSITION  OF  DESIGN  DATA 


00.1  INTRODUCTION. 

Retention  of  Navy  records  is  required  by  SECNAVINST  5210.8D  Department  of  Navy  Chief  Information  Officer 
(DoN  CIO)  dated  31  December  2005,  Department  of  the  Navy  Records  Management  Program.  The 
implementing  instruction  is  SECNAV  M-5210.1,  Records  Management  Manual,  November  2007  (Rev.),  which 
can  be  found  at  http://doni.daps.dla.mi1/SECNAV%20Manualsl/5210.l.pdf. 

This  guide  provides  instructions  for  the  disposition  of  design  project  data  created  by  SEA  05D/V.  Upon 
completion  of  a  project,  and  after  screening  in  accordance  with  this  guide,  retained  project  data  will  be  put  in  a 
long-term  accessible  electronic  format  on  long-term  storage/retrievable  electronic  media.  The  guide  provides  for 
minimum  requirements  that  shall  be  met  by  all  projects.  Proper  disposition  of  project  data  is  a  Ship  Design 
Manager  responsibility.  Proper  disposition  will  assure  the  usefulness  of  these  data  so  future  projects  can  profit  by 
lessons  learned  and  make  use  of  technical  work  already  performed. 

00.2  CATEGORIES  OF  DATA. 

The  data  to  be  deposed  of  by  a  design  project  generally  fall  into  the  following  categories: 

•  Project  required  deliverables. 

•  Technical  data  developed  to  support  deliverables. 

•  Reference  matter  acquired  for  project  use. 

•  Management  reports  such  as  fiscal  reports  and  progress  reports. 

00.3  OBJECTIVES  OF  RETAINING  DATA. 

The  decision  regarding  what  data  are  to  be  retained  after  completion  of  a  design  project  depends  on  the  potential 
need  or  benefit  expected  for  use  of  these  data  as  (a)  reference  use  to  answer  questions  which  may  arise  during  the 
ship  DD&C  period,  (b)  use  in  current/future  design  projects  or  (c)  of  interest  to  future  naval  historians. 

00.4  STORAGE  OF  RETAINED  DATA. 

All  data  whose  retention  is  considered  to  be  in  the  government  interest  shall  be  kept  in  an  accessible  electronic 
form  by  the  05D/V  division  to  which  the  SDM  reports.  It  is  highly  desirable  that  the  material  be  stored  with  links 
to  CDMS  via  the  Navy  Marine  Corps  Internet  (NMCI)  network.  This  will  allow  the  material  to  be  searched  for 
and  used  by  authorized  remotely  located  organizations.  Paper  material  and  removable  electronic  media  such  as 
compact  disks  may  be  sent  to  the  Federal  Record  Center  (FRC)  for  storage.  Note  that  the  FRC  is  now  a 
reimbursable  organization  so  files  kept  there  must  be  paid  for  each  year. 

The  DoN  point  of  contact  for  records  storage  is  Charlie  Barth  -  202-433-2434. 
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00.5  DISPOSITION  OF  DESIGN  PROJECT  DATA. 

During  the  course  of  a  project,  and  particularly  at  the  completion  of  a  project,  data  should  be  reviewed  and  a 
decision  made  as  to  retention  or  disposition.  The  following  steps  are  provided  as  guidance  to  retaining  sufficient 
data  to  meet  the  objectives  of  paragraph  3.0  while  keeping  the  quantity  of  data  retained  to  a  minimum. 

a.  Review  holdings  against  deliverable  requirements  and  fill  deficiencies. 

b.  Purge  the  file  of  insignificant  data,  e.g.,  data  not  required  to  meet  the  objectives  of  paragraph  3.0. 

c.  Purge  the  file  of  all  preliminary  documents  for  which  approved  finals  are  on  file. 

d.  Purge  the  file  of  documents  where  the  data  are  contained  in  summary  documents  such  as  design 
histories. 

e.  Segregate,  identify,  and  purge  duplicates. 

Consideration  should  be  made  to  submit  technical  reports  to  DTIC. 

00.6  DISPOSITION  OF  MODELS  AND  PAINTINGS. 

If  a  physical  model  of  a  ship  or  a  system  is  not  need  by  the  project,  the  Office  of  the  Curator  of  Models,  Code  301 
within  the  Business  Directorate  at  the  David  Taylor  Model  Basin  rhttp://www.dt.navy.mil/cnsm/hist.htmll  should 
be  contacted  to  see  if  the  model  should  be  included  in  the  Navy’s  permanent  collection. 

If  artwork  (such  as  an  oil  painting  or  ink  sketches  representing  the  ship)  is  not  needed  by  the  project,  the  Navy  Art 
Collection  Branch  of  the  Naval  History  and  Heritage  Command  rhttp://www. historv.navy.mil/branches/org6- 
1  .html  should  be  contacted  to  see  if  they  wish  to  include  it  in  the  permanent  collection. 
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APPENDIX  PP 
SYSTEMS  ENGINEERING 

SDMs  and  SIMs  should  be  NAVSEA’s  experts  in  the  conduct  of  systems  engineering.  Per  the  DoD  and 
SECNAV  5000  series,  system  engineering  should  be  a  foundation  for  ship/system  design.  There  is  a  wealth  of 
information  on  the  subject  available  throughout  the  defense  acquisition  community.  Section  2.1  cites  websites 
and  applicable  references.  See  also  Appendix  A  for  selected  references  related  to  the  process.  The  challenge  for 
the  SDMs  and  SIMs  are  to  translate  this  guidance  into  actionable,  practical  advice  for  managing  a  ship/system 
design. 

Figure  PP-1  shows  the  systems  engineering  design  process  featuring  three  stages:  requirements  analysis, 
functional  analysis/allocation,  and  systems  design.  System  analysis  and  control  is  continuously  applied  to  keep 
the  process  on  track.  The  purpose  of  the  requirements  analysis  effort  is  to  properly  identify  and  document  the 
user’s  requirements  and  translate  those  requirements  into  a  set  of  technical  requirements  for  the  system.  During 
functional  analysis/allocation,  the  requirements  identified  in  requirements  analysis  are  translated  into  a  functional 
decomposition  that  describes  the  product  in  terms  of  an  assembly  of  configuration  items  where  each  configuration 
item  is  defined  by  what  it  must  do,  its  required  performance,  and  its  interfaces.  Finally,  during  design  synthesis, 
specific  hardware,  software,  and  “humanware”  (that  is,  human  operators  considered  as  configuration  items  in  the 
functional  analysis)  are  defined  to  meet  the  requirements  of  the  configuration  items.  Systems  analysis  and  control 
provides  the  technical  management  activities  necessary  to  keep  the  entire  process  moving  on  schedule  with 
acceptable  performance  and  cost. 
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This  is  an  idealized  process  and  it  is  typically  interpreted  to  be  serial  and  iterative.  In  practical  application,  all  of 
the  components  occur  concurrently.  Additionally,  the  feedback  loop  from  synthesis  to  requirements  analysis  is 
more  than  just  verification.  The  systems  engineering  process  as  applied  to  ship  design  proceeds  with  the 
following  parallel  efforts: 

•  The  operational  requirements,  policy,  practices,  customs,  and  statutory  requirements  are  analyzed  and 
allocated  to  functional  components  (to  include  humans).  These  become  configuration  items.  The 
probability  that  each  requirement  will  change  over  the  life  cycle  of  the  product  is  assessed  and 
functions  allocated  in  an  attempt  to  isolate  the  impact  of  likely  changing  requirements. 

•  The  configuration  items  are  synthesized  by  selecting  and  designing  system  architectures  and  associated 
hardware,  software,  and  humanware  system  elements.  The  SDM’s/SIM’s  design  organization  is 
generally  aligned  with  these  system  architectures  and  there  is  a  clear  definition  of  responsibility  for 
each. 

•  The  selection  of  hardware,  software,  and  humanware  system  elements  during  synthesis  results  in  the 
creation  of  derived  requirements.  Typically  these  include  specific  details  for  elements  such  as  the 
distributed  systems  onboard  ship  (e.g.,  electrical  power,  compressed  air,  sewage,  potable  water,  etc.). 

•  The  derived  requirements  generated  during  synthesis  feed  back  to  the  requirements  analysis  block,  in 
addition  to  verification  that  the  design  and  the  developed  product  meet  the  requirements.  Feedback 
regarding  functional  analysis  and  allocation  may  develop  additional  configuration  items,  or  change 
existing  configuration  items,  to  fulfill  the  derived  requirements.  These  new  configuration  items  are 
then  synthesized,  which  in  turn  may  create  even  more  derived  requirements.  The  process  continues 
until  the  synthesis  loop  does  not  create  any  additional  derived  requirements  and  the  design  is  verified  to 
satisfy  all  direct,  derived,  and  statutory  requirements. 

The  SDM  must  orchestrate  the  Design  Team  to  conduct  this  process  under  the  watchful  eyes  of  the  Program 
Manager  and  other  interested  parties.  Activities  will  be  conducted  concurrently  and  the  SDM  will  rely  heavily  on 
the  DIM  to  ensure  that  configuration  management  is  implemented  and  that  the  Design  Team  is  informed 
regarding  design  development.  Presentations  and  deliverables  must  be  anchored  in  the  requirements,  whether 
direct,  statutory,  or  derived. 

•  Direct  requirements  are  “owned”  by  the  customer.  Changes  in  them  require  customer  approval.  Many 
are  in  policy,  practices,  and  customs  imposed  by  the  responsible  Program  Office. 

•  Statutory  requirements  are  imposed  from  external  regulatory  bodies  such  as  federal  law  or  other  federal 
agencies  such  as  the  Environmental  Protection  Agency  or  the  USCG.  Ship  classification  societies  such 
as  the  ABS  play  a  significant  role  in  naval  ship  design  for  T-ships.  Even  helicopter  certification  by 
NAVAIR  can  be  considered  as  an  external  requirement  from  the  SDM  perspective,  since  NAVAIR  acts 
as  an  outside  source  of  requirements. 

•  The  designer  controls  derived  requirements.  The  customer  does  not  have  to  approve  changes  to 
derived  requirements,  although  a  successful  SDM  will  work  closely  with  the  Program  Manager  to 
ensure  agreement. 


PP-2 


S9800-AC-MAN-01 0 


There  are  many  tools  and  techniques  available  to  the  SDM/S1M  to  implement  successful  systems  engineering 
throughout  the  design,  and  many  of  these  are  discussed  in  other  sections  of  this  manual.  Recognizing  that 
requirements  management  is  key,  along  with  demonstrating  that  requirements  are  satisfied,  it  is  useful  to  track 
these  requirements  using  a  disciplined  process.  When  an  issue  arises,  knowing  what  organization  must  be 
approached  is  important. 

•  For  direct  requirements,  the  SDM/S1M  will  work  through  the  Program  Manager  to  address  any  issues, 
recognizing  the  distinction  between  customer  requirements,  policy,  practices,  and  customs. 

•  For  statutory  requirements,  interpretation  may  vary  and  the  SDM/S1M  may  need  to  involve  regulatory 
body  representatives  directly  on  the  Design  Team.  Theoretically,  a  program  or  the  customer  can 
negotiate  exemptions  or  waivers  to  statutory  requirements,  but  the  track  record  of  doing  so  within 
reasonable  time  and  costs  for  the  value  of  the  change  is  not  good. 

•  Within  the  Design  Team,  the  SDM  must  have  a  process  for  managing  derived  requirements  and 
maintaining  configuration  control. 

Configuration  management  and  the  resulting  common  understanding  of  the  design  is  what  ties  the  process 
together  and  permits  effective  systems  analysis  and  control. 
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APPENDIX  QQ 

HUMAN  SYSTEMS  INTEGRATION 

NAVSEA  Instruction  3900.8A  ( hyperlink ),  Human  Systems  Integration  (HSI)  Policy  in  Acquisition  and 
Modernization,  establishes  policy  and  responsibilities  within  NAVSEA  including  affiliated  PEOs.  The  NAVSEA 
3900.8-M,  NAVSEA  Human  Systems  Integration  (HSI)  Technical  Processes,  (currently  in  revision  and  formerly 
SEA  05  HSI  Best  Practices  Guide)  is  a  companion  document  that  addresses  specific  HSI  engineering  activities. 

HSI  addresses  the  human  component  (operators,  maintainers,  and  support  personnel)  of  the  total  system  design. 
Just  as  integration  and  information  exchange  requirements  must  be  defined  for  hardware  and  software  interfaces, 
operator  and  maintainer  interfaces  with  hardware  and  software  and  with  one  another  must  be  explicitly  defined 
and  optimized  to  support  overall  system  performance  requirements.  HSI  provides  the  methods  and  discipline  to 
ensure  effective  and  efficient  utilization  of  human  capabilities  and  limitations  within  the  total  system  design. 

The  following  activities  are  fundamental  to  systems  engineering  in  general  and  HSI  in  particular: 

•  A  thorough  understanding  of  total  system  functional  and  performance  requirements  and  expectations 
(This  may  be  achieved  through  execution  of  a  top-down  functional  analysis  or  similar  decomposition 
methods.) 

•  A  thorough  understanding  of  the  roles  of  the  operators  and  maintainers  within  the  system  (This 
requires,  based  on  an  overall  functional  analysis,  an  allocation  of  functionality  among  hardware, 
software,  and  humans.) 

•  Definition  of  the  requirements  and  availability  of  personnel  to  fill  multiple  roles  across  the 
functionality  of  the  system  (This  includes  not  only  watch  standing  duties  associated  with  warfighting 
capabilities  but  also  activities  such  as  training,  maintenance,  and  own-unit  support.) 

•  Subsystems  must  be  optimized  to  support  operator  and  maintainer  performance  and  training 
requirements  -  both  individually  and  across  the  platform  as  a  whole. 

•  Ship-level  T&E  needs  to  incorporate  an  evaluation  of  operator  and  maintainer  performance  and  its 
contribution  to  overall  ship  and  system  performance. 
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HSI  is  composed  of  the  systems  engineering  process  and  program  management  efforts  that  provide  integrated  and 
comprehensive  analysis,  design,  and  assessment  of  requirements,  concepts,  and  resources  for  the  following  HSI 
domains: 

•  Manpower  -  The  numbers  of  personnel  (military,  civilian,  and  contractor)  required,  authorized,  and 
potentially  available  to  operate,  maintain,  train,  administer,  and  support  each  capability  and/or  system. 
(OPNAV  N 1  has  oversight  of  this  area.  The  PEOs  are  responsible  for  working  with  the  manpower 
community  to  determine  the  most  efficient  and  cost-effective  manpower  levels  required  to  attain 
mission  accomplishment.) 

•  Personnel  -  The  human  knowledge,  skills,  abilities,  aptitudes,  competencies,  characteristics,  and 
capabilities  required  to  operate,  maintain,  train,  and  support  each  capability  and/or  system  in  peacetime 
and  war.  (OPNAV  N 1  has  oversight  of  this  area.  The  PEOs  are  responsible  for  consulting  with 
personnel  authorities  to  identify  qualification,  readiness,  personnel  tempo,  and  funding  issues  that 
impact  program  execution.) 

•  Training  -  The  instruction,  education,  and  resources  required  to  provide  Navy  personnel  with  requisite 
knowledge,  skills,  and  abilities  to  properly  operate,  maintain,  train,  and  support  Navy  capabilities 
and/or  systems.  (OPNAV  N15  and  Naval  Education  and  Training  Command  (NETC)  have  oversight 
of  this  area.  The  PEOs  are  responsible  to  consult  with  the  training  community  to  develop  options  for 
individual,  collective,  and  joint  training  for  operators,  maintainers,  and  support  personnel.) 

•  Human  Factors  Engineering  (HFE)  -  The  systems  engineering  design  of  human-machine  interfaces  in 
terms  of  human  performance  requirements,  capabilities,  and  limitations.  (Human-machine  interfaces 
include  those  between  humans  and  information,  environments,  organizations,  operations,  hardware, 
software,  courseware,  and  other  humans.)  (The  application  of  HFE  to  acquisition  activities  is  the 
responsibility  of  the  PEOs.) 

•  Environment,  Safety  and  Occupational  Health  -  The  systems  engineering  process  involving  hazard 
identification,  risk  evaluation,  design  analysis,  hazard  mitigation  and  control,  and  management.  (The 
process  manages  the  design  and  operational  characteristics  of  a  system  that  eliminate  or  minimize  the 
possibilities  for  accidents  or  mishaps  caused  by  human  error  or  system  failure.)  Software  safety  also 
needs  to  be  addressed.  Occupational  Health  is  the  systematic  application  of  biomedical  knowledge, 
early  in  the  acquisition  process,  to  identify,  assess,  and  minimize  health  hazards  associated  with  the 
system’s  operation,  maintenance,  repair,  or  storage.  (The  PEOs  are  responsible  to  ensure  that 
appropriate  ESOH  efforts  are  integrated  across  disciplines  and  into  systems  engineering.  ESOH  in  the 
Navy  is  managed  through  compliance  with  the  National  Environmental  Policy  Act  (NEPA)  and 
Executive  Order  (EO)  12114.)  For  further  guidance  on  NAVSEA  System  Safety,  see  NAVSEAINST 
5100.12  (series),  and  on  Occupational  Safety  and  Health,  see  NAVSEAINST  5100.15  (series). 

•  Personnel  Survivability  -  The  characteristics  of  a  system  that  reduce  the  risk  of  fratricide  and  personal 
detection  or  targeting,  prevent  personal  attack  if  detected  or  targeted,  increase  survival  and  prevent 
injury  if  personally  attacked  or  located  within  an  entity  being  attacked,  minimize  medical  implications 
if  wounded  or  otherwise  injured,  and  minimize  physical  and  mental  fatigue.  Personnel  Survivability  at 
NAVSEA  is  managed  through  the  Damage  Control  and  Personal  Protective  Equipment  competencies 
established  in  SEA  05P. 

•  Habitability  -  System  characteristics  that  provide  living  and  working  conditions  which  result  in  levels 
of  personnel  morale,  safety,  health,  and  comfort  adequate  to  sustain  maximum  personnel  effectiveness 
to  support  mission  performance  and  avoid  personnel  retention  problems.  (The  PEOs  are  responsible  to 
consult  with  the  habitability  community  to  develop  options  for  living  space  designs  that  have  a  direct 
impact  on  quality  of  life  and  morale.  The  Navy  recognizes  that  recruitment  or  retention  may  be 
degraded  by  poor  habitability.  SEA  05P  has  oversight  of  this  area.)  Medical  spaces  are  a  subset  of 
habitability.  The  BUMED  liaison  to  SEA  05P  facilitates  incorporation  of  medical  space  concerns  into 
new  ship  designs  and  modernizations. 
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Under  SECNAVINST  5000.2  ( hyperlink ),  the  Navy  requires  its  Program  Managers  and  Sponsors  to  initiate  an 
HSI  effort  as  early  in  the  acquisition  process  as  possible  and  address  HSI  throughout  all  phases  of  the  acquisition 
process  to  optimize  total  system  performance,  minimize  total  ownership  costs,  and  ensure  that  the  system  is  built 
to  accommodate  the  characteristics  of  the  user  population  that  will  operate,  maintain,  and  support  the  system. 
Human  factors  engineering  and  safety  reviews  should  be  incorporated  into  the  Preliminary,  Contract,  Detail 
Design,  and  Test  &  Evaluation  process. 

The  key  determinant  of  naval  success  in  effective  HSI  integration  with  acquisition  programs  is  integration  with 
systems  engineering  activities.  The  Naval  Systems  Engineering  Technical  Review  Handbook  now  contains 
specific  references  to  HSI  responsibilities  within  the  acquisition  processes  including  specific  guidance  regarding 
HSI  requirements,  processes,  responsibilities,  and  analyses  needed  in  acquisition  programs.  The  SETR  Handbook 
identifies  the  Program  Managers’  HSI  responsibilities  to  work  with  the  manpower,  personnel,  training,  safety  and 
occupational  health,  habitability,  survivability,  and  HFE  communities  to  translate  and  integrate  the  HSI  thresholds 
and  objectives  into  quantifiable  and  measurable  system  requirements.  The  SETR  Handbook  and  other  Naval 
policy  require  HSI  insertion  into  Program  IPTs,  and  Program  documentation  (such  as  the  SEP,  HSIP,  TEMP,  and 
the  SOW).  This  support  strategy  should  help  SEs  identify  responsibilities  and  describe  the  technical  and 
management  approach  for  meeting  the  HSI  requirements. 

Manpower,  personnel,  and  training  optimization  have  a  major  effect  on  ship  performance  and  TOC  and  are  an 
essential  part  of  the  design  process.  Manpower  and  training  KPPs  are  now  mandatory.  SDMs  should  establish 
strategies  early  for  achieving  these  manpower  objectives.  Special  consideration  should  be  given  to  identifying 
and  mitigating  risks  associated  with  ship  manpower  optimization  and  human  performance,  safety,  survivability, 
and  quality  of  life.  This  includes  efforts  to  reduce  the  incidence  and  effect  of  human  errors,  the  direct  cause  of  80 
percent  of  accidents  and  mishaps  on  existing  ships. 

HSI  requirements  are  derived  from  a  top  down  requirements  analysis  directed  at  analysis  and  allocation  of 
function  requirements  to  human  performance  or  to  automation  in  the  context  of  a  mission  scenario,  and 
development  of  requirements  for  manpower  optimization,  workload  reduction,  human-machine  interface  design, 
and  human  performance  requirements  (knowledge,  skills,  and  abilities).  A  budget  line  shall  be  developed  for 
estimating  manpower;  developing  training  requirements  and  concepts;  developing  human-machine  interface 
concepts  and  criteria;  developing  control  space  layouts;  providing  personnel  survivability  and  quality  of  life 
requirements  and  concepts;  providing  medical  space  layouts  and  medical  equipment  requirements;  and  for 
evaluating  and  verifying  human  performance,  workload,  and  safety  for  the  total  ship  as  well  as  for  individual  ship 
systems,  zones,  equipment,  and  facilities.  Depending  on  the  complexity  of  the  HSI  effort,  and  the  relative 
importance  of  manpower  and  human  performance  in  TOC,  the  budget  allocated  to  HSI  studies  will  vary  by 
program. 

At  a  minimum,  HSI  assessments  are  made  formally  at  technical  reviews  and  reflect  the  confidence  of  the 
reviewers  that  the  program  is  on  track  to  deliver  an  acceptable  product.  These  assessments  address  both  program 
process  execution  and  technical  quality.  HSI  assessments  will  take  place  at  or  around  the  following  points: 

•  System  Requirements  Review  (SRR) 

•  System  Functional  Review  (SFR) 

•  Preliminary  Design  Review  (PDR) 

•  Critical  Design  Review  (CDR) 

Draft  criteria  for  each  of  these  HSI  assessments  has  been  developed  for  incorporation  into 
NAVSEAINST  3900. 8B,  the  HSI  Policy  for  Naval  Sea  Systems  Command. 
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Appendix  A  provides  selected  references  with  guidance  related  to  HS1.  The  Naval  HSI  Working  Group,  of  which 
NAVSEA  is  represented,  is  issuing  two  reference  documents  that  will  benefit  NAVSEA  Program  Managers  and 
HSI  practitioners: 

•  HSI  Language  for  Source  Selection  and  Contract  Documentation  Guide  (draft) 

•  The  HSI  Plan  Preparation  Guide  (draft) 
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APPENDIX  RR 
DODAF  ARCHITECTURES 

Architectures  within  the  DoD  are  created  for  a  number  of  reasons.  From  a  compliance  perspective,  the  DoD’s 
development  of  architectures  is  compelled  by  law  and  policy  (i.e.,  Clinger-Cohen  Act,  OMB  Circular  A- 130). 
From  a  practical  perspective,  experience  has  demonstrated  that  the  management  of  large  organizations  employing 
sophisticated  systems  and  technologies  in  pursuit  of  joint  missions  demands  a  structured,  repeatable  method  for 
evaluating  investments  and  investment  alternatives,  as  well  as  the  ability  to  effectively  implement  organizational 
change,  create  new  systems,  and  deploy  new  technologies.  Towards  this  end,  the  DoD  Architecture  Framework 
(DoDAF)  was  established  as  a  guide  for  the  development  of  architectures. 

The  DoDAF  provides  the  guidance  and  rules  for  developing,  representing,  and  understanding  architectures  based 
on  a  common  denominator  across  DoD,  Joint,  and  multinational  boundaries.  It  provides  insight  for  external 
stakeholders  into  how  the  DoD  develops  architectures.  The  DoDAF  is  intended  to  ensure  that  architecture 
descriptions  can  be  compared  and  related  across  programs,  mission  areas,  and,  ultimately,  the  enterprise,  thus, 
establishing  the  foundation  for  analyses  that  supports  decision-making  processes  throughout  the  DoD. 

DoDAF  defines  a  set  of  products  that  act  as  mechanisms  for  visualizing,  understanding,  and  assimilating  the 
broad  scope  and  complexities  of  an  architecture  description  through  graphic,  tabular,  or  textual  means.  These 
products  are  organized  under  four  views:  Operational  View  (OV),  System  View  (SV),  Technical  Standards  View 
(TV),  and  All-View  (AV).  Each  view  depicts  certain  perspectives  of  an  architecture  as  described  below. 

Operational  View 

The  OV  captures  the  operational  nodes,  the  tasks  or  activities  performed,  and  the  information  that  must  be 
exchanged  to  accomplish  DoD  missions.  It  conveys  the  types  of  information  exchanged,  the  frequency  of 
exchange,  which  tasks  and  activities  are  supported  by  the  information  exchanges,  and  the  nature  of  information 
exchanges.  An  example  of  an  OV-1  is  shown  in  Figure  RR-1 .  Currently  there  are  seven  Operational  Views 
defined: 


OV-1  Fligh -Level  Operational  Concept  Graphic 
OV-2  Operational  Node  Connectivity  Description 
OV-3  Operational  Information  Exchange  Matrix 
OV-4  Organizational  Relationships  Chart 
OV-5  Operational  Activity  Model 
OV-6a  Operational  Rules  Model 


OV-6b  Operational  State  Transition  Description 
OV-6c  Operational  Event-Trace  Description 
OV-7  Logical  Data  Model 
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Figure  RR-1.  OV-1  Example 
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Systems  and  Services  View 

The  SV  captures  system,  service,  and  interconnection  functionality  providing  for,  or  supporting,  operational 
activities.  DoD  processes  include  warfighting,  business,  intelligence,  and  infrastructure  functions.  The  SV 
system  functions  and  services  resources  and  components  may  be  linked  to  the  architecture  artifacts  in  the  OV. 
These  system  functions  and  service  resources  support  the  operational  activities  and  facilitate  the  exchange  of 
information  among  operational  nodes.  An  example  of  an  SV-2  is  shown  in  Figure  RR-2.  There  are  currently 
eleven  Systems  and  Services  Views  defined: 


•  SV-1 

•  SV-2 

•  SV-3 

•  SV-4a 

•  SV-4b 

•  SV-5a 

•  SV-5b 

•  SV-5c 

•  SV-6 

•  SV-7 

•  SV-8 

•  SV-9 

•  SV-lOa 

•  SV-1  Ob 

•  SV-lOc 

•  SV-11 


Systems/Services  Interface  Description 
Systems/Services  Communications  Description 

Systems-Systems  Matrix,  Services-Systems  Matrix,  Services- 
Services  Matrix 

Systems  Functionality  Description 
Services  Functionality  Description 

Operational  Activity  to  Systems  Function  Traceability  Matrix 
Operational  Activity  to  Systems  Traceability  Matrix 
Operational  Activity  to  Services  Traceability  Matrix 
Systems/Services  Data  Exchange  Matrix 
Systems/Services  Performance  Parameters  Matrix 
Systems/Services  Evolution  Description 
Systems/Services  Technology  Forecast 
Systems/Services  Rules  Model 
Systems/Services  State  Transition  Description 
Systems/Services  Event-Trace  Description 
Physical  Schema 
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Technical  Standards  View 

The  TV  is  the  minimal  set  of  rules  governing  the  arrangement,  interaction,  and  interdependence  of  system  parts  or 
elements.  Its  puipose  is  to  ensure  that  a  system  satisfies  a  specified  set  of  operational  requirements.  The  TV 
provides  the  technical  systems  implementation  guidelines  upon  which  engineering  specifications  are  based, 
common  building  blocks  are  established,  and  product  lines  are  developed.  It  includes  a  collection  of  the  technical 
standards,  implementation  conventions,  standards  options,  rules,  and  criteria  that  can  be  organized  into  profile(s) 
that  govern  systems  and  system  or  service  elements  for  a  given  architecture.  Currently  there  are  two  Technical 
Standards  Views  defined: 

•  TV-1  Technical  Standards  Profile 

•  TV-2  Technical  Standards  Forecast 

All-View 

There  are  some  overarching  aspects  of  an  architecture  that  relate  to  all  three  views.  These  overarching  aspects  are 
captured  in  the  AV  products.  The  AV  products  provide  information  pertinent  to  the  entire  architecture  but  do  not 
represent  a  distinct  view  of  the  architecture.  AV  products  set  the  scope  and  context  of  the  architecture.  The  scope 
includes  the  subject  area  and  time  frame  for  the  architecture.  The  setting  in  which  the  architecture  exists 
comprises  the  interrelated  conditions  that  compose  the  context  for  the  architecture.  These  conditions  include 
doctrine;  tactics,  techniques,  and  procedures;  relevant  goals  and  vision  statements;  CONOPS;  scenarios;  and 
environmental  conditions.  Currently  there  are  two  All  Views  defined: 

•  AV-1  Overview  and  Summary  Information 

•  AV-2  Integrated  Dictionary 
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APPENDIX  SS 

DESIGN  FOR  PRODUCIBILITY 


55.1  INTRODUCTION. 

This  appendix  describes  policy  and  actions  taken  to  ensure  that  ship  designs  developed  within  SEA  05  incorporate 
design  for  production  among  their  design  criteria.  The  goal  of  design  for  production  is  to  minimize  production 
time  and  cost  by  reducing  shipbuilding  work  content,  while  meeting  mission  performance  requirements. 

The  goal  of  low  cost  and  short  build  time  (that  is.  making  the  design  more  ‘producible’)  is  implicitly  addressed  to 
some  extent  in  all  ship  designs.  However,  the  concept  of  design  for  production  makes  this  need  explicit;  it  is 
formally  included  among  the  design  objectives  to  be  traded  off  in  an  effort  to  arrive  at  the  optimum  multi-criteria 
design.  Some  design  for  production  concepts  have  no  significant  impacts  on  other  requirements  or  on  Shipbuilder 
competition  and  can  be  immediately  adopted.  Others  adversely  impact  other  design  criteria  and  must  be 
evaluated  through  trade-off  studies. 

In  a  few  cases  (notably  the  emergency  cargo  ship  programs  of  World  Wars  I  and  II),  design  for  production  has 
been  a  key  design  driver.  In  other  ship  design  projects,  producibility  has  been  assigned  a  lower  priority  in  favor 
of  other  requirements.  In  general,  it  is  good  practice  to  assess  the  role  of  design  for  production  in  the  ship 
acquisition  program  early  in  the  design  process.  Early  identification  of  the  role  of  producibility  in  achieving 
overall  ship  acquisition  program  objectives  aids  in  specifying  an  effective  schedule  of  design  deliverables.  It  can 
also  allow  for  the  development  of  production  technology  enhancements  that  can  contribute  to  a  more  effective 
ship  acquisition  program. 

The  shipbuilding  industry  plays  an  important  role  in  design  for  production.  Shipbuilders  are  engaged  in  numerous 
efforts  to  streamline  the  transition  from  design  to  production  and  the  Navy  must  ensure  that  the  Contract  Designs 
are  consistent  with  the  Shipbuilders’  processes.  Each  of  the  Shipbuilders  in  the  U.S.  Navy’s  industrial  base  has 
different  facilities  and  producibility  enhancements  must  be  designed  to  be  applicable  to  all  (except  where  the  ship 
acquisition  program  is  limited  to  specified  Shipbuilder(s). 

55.2  SCOPE. 

Guidance  provided  here  applies  to  feasibility  studies,  Preliminary  Designs,  and  Contract  Designs  but  not  Detail 
Design. 

55.3  POLICY. 

55.3.1  Generic  Actions.  SEA  05  ship  design  personnel  shall  budget  for,  and  apply  resources,  to  identify 
producibility  concepts  and  develop  cost/design  impact  relationships.  Effective  practices  for  reducing  ship 
production  cost  and/or  schedule  duration  should  be  identified  and  added  to  SEA  05 ’s  corporate  knowledge. 
Methodologies  to  evaluate  ship  performance  as  a  function  of  producibility-driven  design  changes  must  be 
prepared. 

55.3. 2  Specific  Ship  Designs. 

a.  Examine  producibility  concepts.  Identify  those  having  no  significant  adverse  impacts  on  ship 
performance  or  other  program  needs  and  incorporate  them  into  the  ship  design  baseline.  Producibility 
concepts  having  adverse  impacts  on  other  goals  must  be  evaluated  via  trade-off  studies. 

b.  Industry  and  other  experts  shall  be  invited  to  offer  producibility  guidance  at  appropriate  stages  of  the  ship 
design.  This  guidance  can  be  in  the  form  of  producibility  suggestions  and  proposals,  and  reviews  of  the 
producibility  of  the  ship  design  at  suitable  design  stages. 
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55.4  PROCEDURES. 

Shipbuilding  cost  and  time  is  minimized  when  the  ship  is  designed  to  take  advantage  of  the  most  efficient 
methods  and  technologies  of  construction.  Incorporating  industrial  engineering  considerations  into  the  ship 
design  process  does  this.  A  general  approach  may  be  summarized  as: 

1 .  Identify  key  ship  production  resources  and  constraints. 

2.  Relate  these  to  ship  design  characteristics. 

3.  Adjust  ship  design  characteristics  and/or  apply  new  ship  design  concepts  (consistent  with  meeting  other 
requirements)  to  minimize  use  of  the  key  production  resources  and  to  satisfy  the  constraints. 

a.  It  may  also  be  possible  to  relax  a  constraint  through  development  of  new  industrial  technologies  or 
strategies. 

Steps  #2  and  3  are  challenging  as  they  depend  on  detailed  knowledge  of  Shipbuilder  processes  and  costs.  This 
often  requires  business-sensitive  data.  If  this  data  is  not  available  to  the  Design  Team,  then  experience  and 
general  industrial  engineering  approaches  can  be  used.  Shipbuilders,  shipbuilding  researchers,  and  other  experts 
can  offer  design  for  production  concepts  and  guidance  on  specific  designs. 

Steps  2  and  3  should  be  checked  at  appropriate  design  stages  before  the  aspects  they  impact  are  frozen. 

55.5  PRODUCIBILITY  CONSIDERATIONS. 

The  ship  Design  Team  must  be  aware  of  ongoing  developments  in  Shipbuilder  production  technologies,  as  these 
may  lead  to  changes  in  what  is  producible  and  what  is  not.  Here,  some  currently  applicable  basic  principles  of 
design  for  production  are  offered: 

Some  current  basic  principles  of  design  for  production: 

•  Simplicity  in  design: 

-  Minimum  number  of  parts. 

-  Minimum  number  of  different  parts  and  assemblies. 

-  Minimum  number  of  parts  to  be  formed,  especially  complex  shapes. 

-  Minimum  weld  length. 

-  Avoid  curved  welds  and  welds  that  are  not  parallel. 

-  Minimum  use  of  materials  that  are  slow  or  costly  to  form  and  join. 

-  Minimum  fitting  and  fairing  at  erection  joints. 

-  Elimination  of  need  for  highly  accurate  fitting. 

-  Integration  of  structure  and  outfit. 

-  Elimination  of  staging. 

-  Adequate  access  and  visibility. 

•  Matching  to  Shipbuilder  facilities,  resources,  technologies: 

-  Check  that  blocks  and  machinery  package  units  are  within  Shipbuilder  crane  lift  capacity. 

-  Assembly  and  block  sizes  need  to  fit  panel  line,  workstations,  and  door  openings  in  the 
Shipbuilders. 

-  Design  for  maximum  plate  sizes  and  blocks. 

-  This  minimizes  joint  weld  length,  number  of  parts,  and  material  handling. 

-  Design  for  in-shop  versus  on-ship  work. 

-  Evaluate  required  manual  processing  versus  automated  processing. 

-  Design  out  the  need  for  high  accuracy. 
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These  are  basic  principles.  At  first  glance  they  may  seem  detail-oriented,  but  they  can  impact  the  earliest  stages 
of  ship  design.  (For  example,  selection  of  deck  height  in  a  surface  combatant,  basic  configuration  of  hull 
structure,  and  so  forth.) 

From  these  basic  principles,  the  ship  Design  Team  should  develop  more  detailed  producibility  approaches 
applicable  to  the  specific  ship  design  project.  Some  that  have  often  been  useful  are  suggested  below.  However, 
this  is  not  a  comprehensive  checklist  and  not  all  items  in  this  list  are  applicable  in  every  instance.  Therefore, 
producibility  approaches  must  be  continually  reviewed,  with  new  ones  developed  to  support  each  ship  design 
case. 

Examples  of  design  for  production  suggestions  that  follow  from  the  basic  principles: 

•  Hull  form: 

-  Use  parallel  midbody  and  flat  bottom. 

-  Maximize  flat  plates. 

-  Use  straight  lines  whenever  possible. 

-  Minimize  compound  curves. 

-  Avoid  combined  sheer  and  camber  and  use  straight  lines  for  both. 

•  Structure: 

-  Maximize  uniformity  in  plate  and  stiffener  sizes. 

-  Use  flat  innerbottoms. 

-  Run  deck  longitudinals  parallel  to  ship  centerline  at  bow  and  stern. 

-  Consider  efficient  coating  in  laying  out  the  structure. 

•  Materials: 

-  Define  and  evaluate  the  forming  and  joining  characteristics  of  each  material  under  consideration 
(mild  steel,  high  tensile  steels,  aluminum,  composites,  etc.) 

o  In  most  cases,  lower-technology  materials  are  quicker  and  easier  to  form  and  join. 

•  Arrangements: 

-  Design  for  efficient  block  construction  and  erection. 

o  Work  with  Shipbuilders  to  determine  block  size, 
o  Locate  athwartship  passageways  at  block  breaks, 
o  Avoid  locating  complex  compartments  at  block  breaks, 
o  Design  block  breaks  so  that  blocks  are  self-supporting. 

o  Major  equipment  or  foundations  should  not  extend  over  breaks  between  blocks  and 
assemblies  as  this  will  prevent  the  installation  of  the  equipment  prior  to  joining. 

-  Group  functionally  related  compartments  together. 

-  Maximize  commonality  of  access  penetrations  during  construction  and  post  delivery. 

-  Provide  deck  heights  and  space  arrangements  that  provide  good  access  for  production  work. 

-  Arrange  distributive  systems  to  facilitate  installation. 

•  Machinery  and  combat  systems: 

-  Arrange  machinery  and  combat  systems  to  facilitate  the  use  of  pre -outfitting  packages. 

-  Incorporate  modularity. 

-  Maximize  the  commonality  (i.e.,  reduce  the  variety)  of  equipment,  pre-outfit  packages,  and 
modules. 

-  Use  commercial  machinery  and  equipment  where  acceptable. 

-  Integrate  machinery  foundations  into  the  ship  structure. 

-  Group  small  items  onto  a  common  foundation. 
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55.6  LONG  RANGE  PRODUCIBILITY  ACTIONS. 

To  enable  designers  to  effectively  implement  design  for  production,  some  management  actions  that  are  required 
are: 

•  Train  ship  design  engineers  in  ship  construction  practices  and  design  for  production. 

•  Research  and  develop  evaluation  methodologies  and  cost  estimating  processes  to  allow  evaluation  of 
producibility  concepts  during  early  stage  ship  design. 

•  Consider  changes  to  the  ship  design  process  that  will  facilitate  design  for  modular  construction  during 
early  stage  design. 

•  Incorporate  design  for  production  in  standard  NAVSEA  design  practice. 

55.7  ACQUISITION  PLAN  INTERFACES. 

SEA  05  is  not  only  responsible  for  producing  ship  designs,  but  also  for  developing  trade-off  studies  that  support 
acquisition  program  objectives.  Some  aspects  of  ship  acquisition  planning  that  affect  design  for  production  trade¬ 
offs  are: 

•  Planned  duration  of  DD&C. 

•  Multiple  vs.  single  ship  procurement. 

•  Capabilities  and  breadth  of  the  industrial  base. 

-  Multiple  vs.  single  Shipbuilder. 

-  Characteristics  of  each  Shipbuilder, 

o  Capacity. 

o  Technology, 

o  Facilities, 

o  Labor. 

o  Corporate  strategy  and  core  competences, 

o  Etc. 

-  Characteristics  of  the  vendor  base. 

•  Characteristics  of  the  shipbuilding  contract  (for  example,  fixed  price  vs.  incentive,  etc.) 

Results  of  design  for  production  trade-offs  can  influence  Program  Office  acquisition  strategy  (and  vice-versa),  so 
the  ship  designers  and  the  Program  Offices  must  work  together  on  design  for  production  decisions  and  affected 
aspects  of  the  acquisition  plan.  This  should  be  accomplished  early  enough  in  the  design  cycle  to  be  considered  in 
Preliminary  Design  trade-offs.  This  will  allow  the  results  of  producibility  studies  to  be  considered  in  firming  up 
acquisition  plans.  Ship  Design  Managers  must  provide  ship  acquisition  planning  information  to  the  functional 
codes  to  ensure  that  it  is  included  in  producibility  trade-off  studies  where  applicable. 
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APPENDIX  TT 
COST  ENGINEERING 

This  appendix  prescribes  policy,  responsibilities,  and  procedures  to  ensure  that  cost  is  properly  considered  in 
design  and  engineering  trade-off  decisions  throughout  the  naval  ship  acquisition  design  process  from  Feasibility 
Studies  through  Contract  Design.  This  appendix  addresses  cost  as  a  design  criterion  to  be  invoked  in  all 
NAVSEA  ship  design  projects  under  the  management  of  SEA  05 DAT  It  is  not  intended  to  address  cost  in 
connection  with  ship  alterations  and  FMPs  that  are  the  responsibilities  of  the  Program  Manager,  nor  does  it 
address  cost  related  to  the  POM,  budget,  or  other  NAVSEA  official  estimates  that  are  the  responsibilities  of  SEA 
05C. 

The  effort  involved  in  preparing  costing  documents  can  be  substantial  and  should  be  carefully  planned.  For 
example,  during  Contract  Design  the  CARD  must  describe  the  entire  ship  and  contents  to  a  high  level  of  detail 
and  is  typically  hundreds  of  pages  long.  The  Program  Office  is  responsible  for  the  development  of  the  CARD 
which  includes  significant  input  from  the  SDM. 

Discussion 

Cost  engineering  analysis  has  a  continuing  role  throughout  design.  It  can  provide  the  cost  information  needed  for 
concept  selection,  subsystem  optimization,  equipment  selection,  and  cost  control.  The  cost  engineering  function 
must  be  recognized  as  an  important  and  integral  part  of  the  design  process  along  with  ship  design  and  systems 
engineering.  For  economic  effectiveness,  every  design  and  engineering  decision  must  include  cost  as  a  pertinent 
parameter. 

Policy 

During  ship  design  and  development,  cost  requirements  and  the  achievements  of  cost  goals  will  be  evaluated  with 
the  same  rigor  as  technical  requirements  and  the  achievement  of  performance  goals.  Practical  trade-offs  between 
system  capability,  cost,  and  schedules  must  be  continually  examined  to  ensure  that  the  systems  developed  will 
have  the  lowest  life  cycle  cost  consistent  with  schedule  and  performance  requirements.  Therefore  all  new  ship 
acquisition  design  projects,  modified  repeats,  and  major  ship  conversions  shall  include  cost  engineering  analysis 
as  a  requirement  in  performing  ship  design  trade-offs. 

Ship  design  participants  shall  consider  cost  as  an  integral  part  of  their  trade-off  studies  throughout  the  ship 
acquisition  design  process.  This  policy  applies  not  only  to  in-house  designs  but  also  to  Contractor  Designs  and  to 
all  design  agents. 

Responsibilities 

The  PNA  is  responsible  for  ensuring  that  cost  engineering  analysis  is  included  as  an  essential  paid  of  the 
Feasibility  Study  POA&M  and  that  task  funding  for  cost  engineering  analysis  is  included. 

The  SDM  is  responsible  for  ensuring  that  cost  engineering  analysis  is  included  as  an  essential  part  of  the 
Statement  of  Work  in  the  Management  Plan  for  Preliminary  Design,  and  for  Contract  Design,  modified  repeats, 
and  major  conversions  and  that  task  funding  for  cost  engineering  analysis  is  included.  Statement  of  Work  for 
Contractor  Ship  Designs  shall  also  include  provisions  for  cost  engineering  analysis  in  support  of  design  trade-offs. 

SEA  05C  is  responsible  for  providing  historical  and  current  cost  data,  economic  and  programmatic  factors,  and 
overall  policy  guidance  in  support  of  cost  engineering  analyses. 

Each  SEM  and  TL  is  responsible  for  considering  the  cost  impact  of  their  design  decisions  in  trade-off  studies. 
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Procedures 

Cost  and  Feasibility  Studies  will  require  major  ship  characteristics  trade-offs  to  produce  a  mix  of  ship  designs 
with  appropriate  hull  forms  covering  a  reasonable  range  of  capabilities.  Typical  characteristics  issues  would 
include  weapons,  sensors,  speed,  endurance,  and  survivability  which  affect  both  ship  size  and  cost.  The  viable 
options,  with  their  preliminary  characteristics,  and  ROM  acquisition  cost  and  total  life  cycle  cost,  will  be 
provided.  These  official  estimates  for  lead  ship,  first  follow  ship,  and  ship  class  average  are  prepared  by  SEA 
05C.  Cost  estimates  for  trade-off  studies  to  support  design  decisions,  however,  are  prepared  by  the  SCM  or  SDM. 

At  the  initiation  of  Preliminary  Design,  a  ship  cost  baseline  consistent  with  the  approved  NAVSEA  official 
estimate  will  be  established  for  tracking  major  trade-off  decisions  and  changes  in  ship  requirements.  For 
traceability  of  successive  cost  estimates,  the  SDM  will  allocate  cost  budgets  to  the  SEMs  and  estimate  the  cost 
impact  of  their  trade-off  studies  on  the  Allocated  Baseline  cost.  Typical  design  trade-off  issues  could  include  the 
heights  of  decks  throughout  the  ship;  distribution  of  different  types  of  structural  materials  in  the  hull;  frame 
spacing;  superstructure  material;  habitability  schemes;  manning  and  maintenance  levels;  type  of  propulsion, 
electrical,  and  auxiliary  plants;  number  and  capacity  of  major  HM&E  equipment;  and  selection  of  major  combat 
system  components.  Trade-off  results  are  evaluated  on  the  basis  of  total  ship  impact  that  should  include,  but  not 
be  limited  to,  such  considerations  as  the  impacts  on  weight,  space,  electric  power,  manning,  maintenance, 
reliability,  and  survivability  versus  impacts  on  acquisition  and  life  cycle  cost.  The  final  Preliminary  Design 
configuration,  which  should  be  the  basis  for  a  budget  quality  cost  estimate,  will  be  documented  in  the  Preliminary 
Design  Report. 

During  Contract  Design: 

•  The  ship  cost  baseline  will  be  refined. 

•  Detailed  weight  estimates  will  be  produced. 

•  Producibility  issues  will  be  investigated. 

•  Lower  level  trade-off  studies  will  be  performed. 

•  Functional  codes  will  identify  and  provide  technical  data  on  alternate  design  configurations  at  both  the 
subsystem  and  equipment  level. 

•  Specifications  and  drawings  will  be  developed. 

Typical  options  could  include  such  items  as  types  of  fuel/ballast  systems,  levels  of  passive  protection,  types  of 
distilling  units,  and  kinds  of  piping  materials.  The  Cost  Engineer  on  the  Design  Team  will  provide  the  installed 
costs  of  the  options  to  the  system’s  designer  or  engineer  for  comparative  cost/benefit  analysis  to  be  used  as  a  basis 
for  selection  or  recommendation.  Trade-off  decisions  and  refinements  in  the  Contract  Design  Weight  Estimate 
will  be  reflected  in  the  updated  ship  cost  baseline  on  a  periodic  or  as  needed  basis.  An  analysis  of  the  changes 
from  the  previous  update  will  be  reported.  At  the  completion  of  the  Contract  Design,  the  Contract  Design  Report 
will  be  developed  summarizing  how  the  ship  design  meets  the  requirements  and  constraints  of  the  CDD. 

The  degree  of  design  and  cost  information  available  for  the  development  of  ship  end  cost  estimates  varies 
considerably  from  the  time  a  ship  is  initially  identified  to  the  time  a  shipbuilding  contract  is  awarded.  To  indicate 
the  degree  of  maturity  and  reliability  of  cost  estimates  a  system  of  classifications  and  Cost  Readiness  levels 
(CRLs)  for  ship  cost  estimates  is  provided  in  NAVSEAINST  7300. 14  (hyperlink).  Classifications  of  budget, 
feasibility,  and  Rough  Order  of  Magnitude  (ROM)  with  CRLs  of  6-9,  4-5,  and  1-3  respectively  are  indicators  of 
the  availability  and  degree  of  detail  of  technical  design,  program  planning,  and  economic  information.  A  separate 
assessment  of  the  confidence  level  of  the  estimate  is  provided  by  SEA  05C  through  a  cost  risk  curve  that  defines 
the  probability  that  a  program  can  be  executed  within  a  given  estimate. 
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The  determination  of  the  CRL  and  subsequent  cost  classification  for  a  given  estimate  is  based  on  the  evaluation  of 
a  combination  of  attributes  related  to  the  maturity  of  the  design,  cost,  and  programmatic  components  of  the 
estimate.  The  cost  engineer  in  developing  the  CRL  should  consider  characteristics  such  as  depth  of  the  design 
data  available,  economic  or  market  conditions  and  assumptions,  maturity  of  design  and  technology  of  individual 
ship  system  technologies,  and  the  overall  maturity  of  the  ship  platform  design  and  technology.  These 
characteristics  should  be  evaluated  relative  to  the  cost  impact  of  specific  characteristics  on  the  overall  cost 
estimate. 

As  an  example,  in  considering  the  appropriate  CRL  for  a  ship  cost  estimate  of  a  modified  in-service  ship  design 
that  includes  a  new  advanced  radar  system  and  a  cutting  edge  developmental  propulsion  plant,  individual  major 
components  could  be  at  significantly  different  classification  levels  based  on  the  maturity  of  cost  and  technical 
characteristics.  In  this  instance  the  CRLs  associated  with  the  individual  components  might  be  values  such  as: 


Ship  System  Area  CRL 

Reuse  of  proven  hull  7 

Advanced  radar  with  some  development  complete  4 
Propulsion  Plant  in  very  early  concepts  2 


Based  on  an  assessment  of  the  relative  cost  impacts  of  the  ship  system  areas  and  overall  CRL  for  the  ship  cost 
estimate  could  be  in  the  “Feasibility”  cost  category  and  have  a  Cost  Readiness  Level  of  4  or  5  depending  on  the 
actual  cost  impacts  for  the  ship  system  areas. 

The  intended  use  and  a  brief  description  for  each  classification  of  a  cost  estimate  are  as  follows: 

Budget  Quality  Estimate  (CRL  6-9) 

This  is  the  highest  quality  estimate  in  the  planning,  programming,  budget,  and  execution  process  for  a  new 
construction  ship.  A  budget  quality  estimate  is  recommended  to  be  used  for  budget  submittals  for  the  current 
budget  year. 

Generally,  a  budget  quality  cost  estimate  is  developed  by  the  professional  cost  engineers  in  SEA  05C,  and  is 
associated  with  a  cost  risk  curve  that  defines  the  probability  that  a  program  can  be  executed  within  a  given 
estimate.  In  most  circumstances  the  cost  risk  curve  should  have  a  more  narrow  range  as  the  CRL  increases  from 
CRL  1  through  CRL  9  and  the  cost  category  changes  from  ROM,  Feasibility  and  Budget  Quality  as  more  mature 
data  and  methodology  is  used  for  the  development  of  the  cost  estimate. 

A  budget  quality  cost  estimate  is  based  on  a  Preliminary  Design  and  associated  three-digit  SWBS  level  weight 
estimate.  A  list  of  potential  Shipbuilders  will  support  development  of  appropriate  labor  rate,  overhead  rate,  and 
other  factors  such  as  profit  and  cost  of  money,  as  applicable.  Industry  analysis  will  establish  realistic  award  dates 
and  build  periods. 

Projected  Shipbuilder  escalation  cost  calculations  should  be  based  on  Program  Manager  developed  ship  contract 
award,  start  of  construction,  and  delivery  schedules  and  SEA  05C  realistic  shipbuilding  indices. 

The  maturity  of  technical  design  characteristics,  program  planning,  and  economic/market  conditions  and 
assumptions  should  be  considered  by  the  SEA  05C  cost  engineer  in  development  of  the  appropriate  CRL  “score.” 
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Feasibility  Design  Estimate  (CRL  4-5) 

Feasibility  design  estimates  are  those  costs  prepared  using  design  information  available  from  ship  feasibility 
studies.  The  feasibility  study  produces  three-digit  SWBS  weight  data  and  general  guidance  with  respect  to  major 
electronics  and  weapons  systems,  but  may  not  identify  all  major  equipment  items  that  have  significant  cost 
impact.  Feasibility  studies  are  often  conducted  before  program  requirements  are  finalized.  Cost  estimates  that  fit 
into  this  category  include  those  derived  by  inflating  to  current  dollars  a  previous  cost  for  a  similar  ship  and 
making  gross  adjustments  for  expected  changes  in  design,  program  requirements,  and  program  cost  factors.  A 
cost  estimate  that  is  derived  from  a  current  POM/Budget  estimate  by  deflating  or  inflating  to  some  other  year 
using  shipbuilding  labor  and  material  escalation  would  be  considered  a  feasibility  design  estimate.  The  major 
elements  generally  missing  that  necessitate  using  a  designation  of  a  feasibility  design  estimate  rather  than  budget 
quality  are  the  lack  of  a  completed  Preliminary  Design  and  current  economic/market  conditions  and  assumptions. 
The  cost  risk  curve  for  a  feasibility  design  estimate  would  in  most  circumstances  have  a  wider  range  than  the 
curve  for  a  budget  quality  estimate. 

ROM  Estimate  (CRL  1-3) 

An  ROM  estimate  is  based  on  design  information  that  does  not  meet  the  standards  equivalent  to  a  ship  feasibility 
study.  The  design  study  may  produce  rough  order  ship  weights,  but  the  basis  for  the  weights  and  other  ship 
design  parameters  may  be  engineering  judgment  rather  than  analysis.  Some  examples  are:  (1)  a  new  design  of  an 
unconventional  ship  platform,  (2)  a  ship  concept  design  effort  with  insufficient  time  or  resources  to  validate  key 
assumptions  with  analysis,  (3)  a  ship  platform  that  is  initially  designed  to  carry  unconventional  or  developmental 
equipment,  and  (4)  a  ship  designed  beyond  the  current  state  of  the  art.  Other  conditions  that  call  for  use  of  the 
ROM  category  are: 

•  Inflating  a  historical  total  ship  cost  10  years  or  more,  because  such  a  time  span  is  sufficiently  long  to 
generate  a  potential  for  changes  in  specification  or  outdating  of  technology 

•  Projecting  out  year  ship  costs  beyond  the  current  POM  where  long  range  economic  and  ultimate  ship 
configuration  uncertainties  are  attendant  with  such  projections 

•  Using  nation-wide  or  area-wide  labor  and  overhead  rates  instead  of  yard  specific  rates.  Possible  use  of 
a  composite  of  a  group  of  Shipbuilder  rates  based  on  the  type  of  ship. 

A  cost  risk  curve  for  a  ROM  would  normally  have  the  widest  range,  reflecting  the  increased  range  of  uncertainty 
for  the  estimate. 

Directed  or  Modified  Estimate 

A  cost  estimate  that  is:  (1)  not  developed  by  SEA  05C  through  the  normal  estimating  process,  (2)  provided  by 
other  commands  or  agencies,  or  (3)  directed  by  higher  authority  will  be  classified  as  Directed.  Directed  cost 
estimates  are  generally  a  total  cost  limitation  that  is  established  without  the  benefit  of  a  fully  developed  design 
concept  and  related  cost  estimate. 

A  directed  estimate  is  generally  any  previous  cost  estimate  (Cost  Readiness  Levels  1-9)  that  was  changed  to 
conform  to  budget  cuts  or  restrictions  on  a  total  cost  that  is  not  based  on  an  estimate  developed  through  the 
normal  estimating  process.  Directed  estimates  are  sometimes  referred  to  as  “Congressional  Control  Number,” 
“OPNAV  Control  Number,”  or  “OPNAV  Planning  Wedge.” 
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APPENDIX  UU 

COST  AS  AN  INDEPENDENT  VARIABLE 


Cost  As  an  Independent  Variable 

With  a  Cost  As  an  Independent  Variable  (CAIV)  approach,  operational  requirements  provided  by  the  customer 
are  given  in  terms  of  threshold  and  objective  values.  The  range  between  these  two  values  provides  the  Program 
Manager  with  trade-space  to  match  the  available  funds  with  the  capabilities  that  can  be  bought  for  that  amount  - 
the  total  program  cost  remains  a  constant. 


Time 


CAIV  Target  -  Dollar  Value  that  the  program 
office  is  managing  to. 

Cost  Uncertainty  Region  -  The  range  of 
predicted  costs  within  a  given  confidence  level. 
There  is  no  guaranty  that  the  actual  program 
costs  will  fall  within  this  range.  If  they  don’t 
however,  cost  overruns  are  certain. 


The  CAIV  theory  is  graphically  illustrated  to  the  left 
and  is  predicated  on  the  assumption  that  the  final 
program  costs  (focusing  for  now  on  procurement  rather 
than  life  cycle)  are  directly  dependent  on  the  capability 
requirements  and  can  be  predictably  influenced  as 
needed  during  acquisition.  In  practice,  though,  much 
of  the  final  cost  of  an  acquisition  program  is  fixed 
early  in  the  design  process  through  decisions  on  basic 
design  architecture  and  requirements  allocation  (both 
operational  and  derived)  to  systems.  Unfortunately, 
while  much  of  the  cost  is  determined  early  in  the 
design  process,  estimating  that  cost  to  any  degree  of 
certainty  is  nearly  impossible.  As  the  costs  of  the 
program  are  better  understood,  the  remaining  design 
flexibility  to  adjust  to  increasing  costs  may  not  be 
sufficient  to  enable  the  Program  Manager  time  to  take 
corrective  action  when  the  cost  estimates  indicate  a 
possible  problem. 


Successfully  implementing  CAIV  depends  on  understanding  certain  cost  estimating,  system  architecting,  and 
program  management  principles. 
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Cost  Estimating  for  CAIV 

In  CAIV,  a  program  budget  is  set  somewhere  between  the  estimated  levels  needed  to  achieve  operational 
requirement  threshold  and  objective  values.  The  range  between  these  two  values  is  intended  to  provide  the 
Program  Manager  with  trade-space  to  match  available  funds  with  the  capabilities  that  can  be  bought  for  that 
amount.  The  CAIV  target  (a  dollar  value  that  the  Program  Office  will  manage  to)  must  be  set  at  or  above  the 
actual  costs  to  achieve  threshold  program  capabilities,  or  else  there  will  be  no  chance  that  the  program  will  remain 
within  budget.  Actual  costs,  of  course,  are  only  known  with  certainty  after  the  product  has  been  delivered. 
Therefore,  the  cost  estimate  that  is  used  to  establish  the  CAIV  target  is  critical  to  program  success. 

A  good  ship  acquisition  cost  estimates  can  be  considered  to  have  two  distinct  elements.  The  first  is  the  Design 
Cost  Estimate  and  is  based  on  the  known  characteristics  of  a  specific  design  point  between  the  threshold  and 
objective  values  for  each  requirement.  It  does  not  take  technical  or  program  risks  into  account.  The  second  and 
often  neglected  portion  of  the  CAIV  cost  estimate  is  a  Risk  Contingency- 

Better  Risk  Contingencies  -  Budgeting  for  Risk 

For  many  programs,  cost  estimates  for  a  system  do  not  directly  account  for  technical  risks.  If  technical  risks  are 
accounted  for  at  all,  their  impact  is  assessed  as  a  gross  fraction  of  the  total  ship  cost.  Most  alarming,  risk- 
reduction  activity  is  considered  “non-value  added”  because  this  activity  does  not  impact  the  material  properties  of 
the  end  product.  By  not  properly  accounting  for  risk  in  cost  estimation,  a  Program  Manager  will  be  tempted  to 
cut  risk  reduction  activity  because  the  cost  estimation  methodology  only  includes  the  cost  of  the  risk  reduction 
activity  and  not  the  reduction  in  the  cost  of  the  risk  contingency  due  to  the  resulting  reduction  in  risk.  Within 
these  cost  models,  risk-reduction  activity  only  adds  costs;  hence  they  suggest  that  risk  reduction  activity  should 
perversely  be  eliminated. 

Cost  Terms  and  Relationships 

Product  Cost 

Final  Product  Cost  =  /(Final  Requirements,  Requirement  Change  Costs) 

Requirement  Change  Costs  =  /(Design  Flexibility  at  Time  of  Change) 

Cost  Estimating 

Overall  Cost  Estimate  =  Design  Cost  Estimate  +  Risk  Contingency 
Overall  Cost  Uncertainty  =  Design  Cost  Uncertainty  +  Risk  Contingency 
Uncertainty 

Design  Cost  Uncertainty  =  /(Cost  Estimating  Methods) 

Risk  Contingency  Uncertainty  =  /(Risk  Levels,  Risk  Mitigation  Cost 
Estimating  Methods) 

Cost  As  an  Independent  Variable  (CAIV) 

CAIV  Target  =  Dollar  Value  that  the  program  office  is  managing  to 

Cost  Margin  =  The  difference  between  the  CAIV  Target  and  the  Cost  Estimate 
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The  SDM  and  SIM  risk  assessments  are  vital  for  determining  a  reasonable  Risk  Contingency  based  on  adverse 
outcome  probabilities  and  consequences.  Ideally  a  cost  contingency  should  be  incorporated  for  each  risk  in  the 
program  risk  register.  The  cost  contingency  should  be  considered  an  “insurance”  payment  to  account  for  the 
impact  on  the  ship  program  should  the  risk  be  realized.  Because  the  likelihood  of  a  risk  outcome  is  not  100 
percent,  (if  so,  then  it  would  be  a  problem  and  not  a  risk)  the  cost  contingency  reserved  for  a  risk  should  typically 
be  a  fraction  of  the  cost  to  recover  from  the  risk  outcome.  This  fraction  will  depend  on  the  aggregation  of  all 
program  risks,  and  the  program’s  risk  tolerance.  Within  a  CAIV  environment,  the  sum  of  the  cost  margin  plus  the 
cost  contingency  should  have  a  high  probability  (say  90  percent)  of  being  sufficient  to  fund  the  aggregation  of 
realized  risks  as  well  as  risk  mitigation  efforts  designed  to  reduce  cost  contingency  requirements. 

Implementing  a  good  cost  contingency  method  requires  careful  definition  of  risk  outcomes  as  well  as  allocating 
cost  contingencies  only  when  risks  are  realized  or  for  cost-effective  risk  mitigation.  Risk  outcomes  should  be 
defined  in  terms  of  precisely  what  adverse  event  will  occur  and  what  required  efforts  would  be  needed  to  recover 
from  the  adverse  event.  A  Program  should  conduct  a  risk  mitigation  activity  if  the  cost  of  the  risk  mitigation 
activity  is  less  than  the  reduction  in  cost  contingency  for  that  risk  that  is  realized  by  the  risk  mitigation  effort. 

If  cost  contingencies  are  allocated  to  non-risk  mitigation  activities  before  risks  are  realized,  the  funds  will  likely 
be  spent  without  mitigating  or  recovering  from  the  realized  risk.  The  effect  of  “Money  allocated  is  Money  Spent” 
becomes  evident.  Careful  management  of  the  cost  contingency  funds  is  needed  to  ensure  work  is  conducted  in  a 
controlled-risk  manner  to  avoid  unforeseen  problems  while  undertaking  cost-effective  risk  mitigation  efforts. 

The  Cost  Uncertainty  Region 

Both  the  Design  Cost  Estimate  and  Risk  Contingency  portions  of  the  overall  cost  estimate  will  have  uncertainties, 
because  development  and  construction  of  a  complex  system  is  difficult  to  predict  with  precision.  Often,  the 
acquisition  schedule  will  span  10  to  20  years,  and  many  of  the  assumptions  used  to  develop  a  cost  estimate  will 
prove  to  be  incorrect.  Sources  of  uncertainty  include: 

•  Changes  in  labor  rates 

•  Changes  in  material  rates 

•  Uncertainty  in  the  amount  of  manhours  needed  (especially  true  for  new  technology) 

•  Contractor  expertise  (competition  for  workforce  with  other  industries) 

•  Cash  flow  impacts  (generally  a  result  of  program  funding  instability) 

•  Poorly  specified,  misunderstood,  or  emergent  safety  requirements  requiring  rework 

•  Realized  risks  -  problems 

•  Unpredicted  problems 

•  Waste 

Furthermore,  existing  financial  management  policies  discourage  Program  Managers  from  maintaining  a 
contingency  fund  for  addressing  much  of  the  cost  uncertainty.  Funds  allocated  for  change  orders  can  only  be  used 
to  address  poorly  specified,  misunderstood,  or  emergent  safety  requirements  requiring  rework.  Management 
Reserve  is  used  to  address  realized  risks  and  unpredicted  problems.  Funds  are  not  typically  allocated  to  cover 
other  sources  of  uncertainty. 

Removing  sources  of  cost  risk  from  a  program  is  an  effective  way  of  reducing  the  amount  of  Risk  Contingency 
needed.  Some  elements  of  cost  uncertainty  are  outside  the  control  of  a  Program  Manager.  Inflation  for  example, 
is  very  difficult  to  predict  but  can  have  a  major  impact  on  the  cost  of  materials.  Forcing  a  Program  Manager  to 
account  for  inflation  within  a  CAIV  environment  may  in  itself  consume  all  cost  flexibility.  Instead,  that  portion 
of  the  cost  of  a  product  allocated  to  materials  can  be  adjusted  according  to  a  standard  industry  index.  The  Bureau 
of  Fabor  Statistics  publishes  a  number  of  indices  that  could  be  used.  In  previous  years,  ship  acquisition  program 
used  this  method  in  the  form  of  Escalation  Payments. 
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Key  to  implementing  CAIV  is  keeping  Committed  Costs  (due  to  design  decisions)  below  the  minimum  bound  of 
the  Cost  Uncertainty  region.  Unfortunately,  determining  either  the  Committed  Cost  or  the  Cost  Uncertainty 
region  with  any  precision  is  extremely  difficult,  if  not  impossible.  Therefore,  good  cost  estimating  techniques 
alone  will  not  keep  a  program  out  of  trouble.  System  architecting  and  program  management  CAIV  principles  are 
also  needed. 

System  Architecting  for  CAIV 

One  of  the  fundamental  CAIV  ideas  is  that  a  program  can  control  costs  by  managing  required  capability  levels. 
This,  however,  is  only  true  if  the  design  is  flexible  enough  so  that  change  costs  do  not  dominate  cost  versus 
requirements  relationships. 

Improving  Design  Flexibility  through  Modularity 

Modularity  implemented  in  a  scalable  architecture  enables  the  development  of  subsystems  independent  of  the 
overall  platform  development.  To  work  in  a  CAIV  environment,  providing  scalable  performance  at  scalable  cost 
is  critical.  Furthermore,  the  architecture  should  enable  the  Program  Manager  to  delay  deciding  how  much 
performance  to  provide  for  as  long  as  possible  without  impacting  the  cost -performance  relationship. 

The  systems  architect  should  use  modularity  strategically  to  control  costs.  Areas  to  apply  modularity  include: 

•  Material  solutions  to  address  operational  requirements  with  a  threshold  and  objective  value.  The 
modularity  should  enable  a  scalable  solution  to  cover  most  or  the  entire  threshold  to  objective  range. 

•  Material  solutions  for  technologies  that  are  anticipated  to  become  obsolete  and  not  logistically 
supportable  during  the  design  service  life  of  the  system. 

•  Material  solutions  for  operational  requirements  likely  to  change  over  the  life  of  the  system. 

In  each  of  these  cases,  the  modularity  must  enable  a  cost-effective  change  in  system  capability. 

Examples  of  modularity  that  preserve  flexibility  for  the  Program  Manager  in  adjusting  system  performance  to 
meet  cost  targets  include: 

•  Sizing  modular  radar  arrays  to  achieve  the  objective  value,  but  only  partially  populating  the  radar  array. 

•  For  distributed  systems  such  as  electrical  power  and  chill  water,  design  the  system  for  full  service  life 
allowances,  but  only  populate  generation  and  distribution  system  “modules”  to  meet  the  delivery 
condition.  The  system  design  must  incorporate  the  ability  to  easily  add  the  modules  to  achieve  full 
service  life  requirements. 

•  Sizing  network  equipment  racks  to  hold  the  full  number  of  blade-servers  to  meet  objective 
requirements,  but  only  partially  populating  racks  with  blade-servers. 

•  Designing  a  scalable  software  architecture  that  is  capable  of  achieving  objective  requirements,  but  only 
developing,  testing,  and  installing  software  modules  to  achieve  a  lesser  level  of  performance. 

•  For  ships  with  an  Integrated  Power  System,  design  the  power  generation  and  propulsion  motors  to 
achieve  a  sustained  speed  greater  than  threshold  speed.  Use  some  portion  of  the  power  generation 
installed  above  threshold  speed  as  a  design  and  construction  margin  and/or  service  life  margin. 

Reinertsen1  describes  three  underlying  principles  for  developing  a  product  architecture: 

•  Make  decisions  with  regard  to  how  modular  to  make  the  product 

•  Partition  the  design  to  control  the  impact  of  variability 

•  Manage  the  internal  interfaces  of  the  design 


1  Reinertsen,  Donald  G.,  “ Managing  The  Design  Factory’:  A  Product  Developer's  Toolkit,  ”  The  Free  Press,  New  York,  New 
York,  1997 
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With  respect  to  modularity,  he  states  that  the  secret  art  of  product  architecture  is  that  the  benefits  will  only  come 
when  the  system  is  portioned  properly  and  the  interfaces  are  properly  defined  and  stable.  Stable  interfaces  require 
an  adequate  margin  to  prevent  changes  during  the  design  and  the  resultant  rework. 

Reinertsen  emphasizes  that  a  broad  benefit  of  modularity  is  that  it  permits  reuse  of  modules  from  other  designs. 

A  carefully  designed  reuse  plan  can  save  enormous  amounts  of  design  time  and  expenses.  Within  the  CAIV 
environment,  each  increment  of  performance  corresponds  to  a  different  systems  design  and  corresponding  cost. 
The  reuse  in  this  context  is  the  reuse  of  design  work  for  different  levels  of  performance. 

Estimating  system  costs  of  modular  systems  is  not  easy.  At  the  interface  level,  costs  usually  increase  because  we 
add  parts  and  potentially  complexity.  At  the  module  level,  costs  can  either  rise  or  fall  because  the  module  is 
designed  to  meet  the  needs  of  many  system  designs  instead  of  just  one.  The  cost  impact  of  modularity  depends  on 
both  cross-program  economics  and  the  need  to  accommodate  many  “designs”  to  implement  CAIV,  and  cannot  be 
assessed  on  the  basis  of  a  single  design.  For  a  CAIV  program,  the  greater  the  number  of  times  that  requirements 
are  adjusted  to  maintain  the  cost  target,  the  required  non-recurring  engineering  to  implement  the  change  in 
requirements  will  likely  be  increasingly  less  for  modular  systems  than  for  non-modular  systems. 

If  not  done  properly,  modularity  can  affect  performance.  Interfaces  can  act  as  bottlenecks  as  compared  to  a 
tightly  coupled  non-modular  system.  As  a  result,  Reinertsen  differentiates  between  low-expense  architectures, 
low-cost  architectures,  high-performance  architectures,  and  fast-development  architectures.  He  particularly 
emphasizes  that  architecture  should  be  an  economic  decision,  not  a  technical  one.  Technical  people  are  still  likely 
to  play  a  dominate  role  in  selecting  the  architecture;  however,  they  cannot  do  the  job  alone.  Acquisition 
professionals,  ship  design  engineers,  and  cost  engineers  must  collaborate  from  the  earliest  stages  of  design. 

Improving  Design  Flexibility  through  Set-Based  Design 

Set-Based  Design,  as  described  by  Bernstein2,  preserves  design  flexibility  through  three  basic  tenets: 

•  “Understand  the  design  space 

-  Define  feasible  regions 

-  Explore  trade-offs  by  designing  multiple  alternatives 

-  Communicate  sets  of  possibilities 

•  Integrate  by  intersection 

-  Took  for  intersection  of  feasible  sets 

-  Impose  minimum  (maximum)  constraint 

-  Seek  conceptual  robustness 

•  Establish  feasibility  before  commitment 

-  Narrow  sets  gradually  while  increasing  detail 

-  Stay  within  set  once  committed 

-  Control  by  managing  uncertainty  at  process  gates” 

As  an  example  of  how  set-based  design  has  been  applied  in  commercial  industry,  Ward  et.  al:'  describe  Toyota’s 
successful  implementation  of  set-based  design  to  produce  competitive  automotive  designs  faster  and  cheaper  than 
traditional  design  methods. 


2  Bernstein,  Joshua,  “Design  Methods  in  the  Aerospace  Industry:  Looking  for  Evidence  of  Set -Based  Practices,”  Thesis  for 
the  degree  of  Master  of  Science  at  the  Massachusetts  Institute  of  Technology,  Technology  and  Policy  Program,  May,  1998. 

3  Ward,  A.,  J.  K.  Liker,  J.  J.  Cristiano,  and  D.  K.  Sobek  II,  “The  Second  Toyota  Pardox:  How  Delaying  Decisions  Can  Make 
Better  Cars  Faster,”  Sloan  Management  Review,  Spring  1995. 
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In  a  set-based  design  process,  engineers  of  different  systems  (i.e.,  electrical  systems,  combat  systems,  hull  design, 
etc.)  communicate  ranges  of  solutions  with  associated  derived  requirements  on  other  systems  and  levels  of 
performance.  As  shown  below  in  the  figure,  regions  of  feasibility  are  determined  by  intersecting  different  ranges 
of  solutions  offered  by  the  different  engineering  disciplines.  Initially,  the  ranges  of  discipline  solutions  may  need 
to  grow  to  enable  a  sufficiently  large  region  of  feasibility  at  the  intersection  of  independent  solutions.  The  range 
of  solutions  for  each  engineering  discipline  is  then  reduced  at  the  process  gates  to  eliminate  subsystem  solutions 
that  are  not  likely  to  contribute  to  a  total  system  solution.  Following  the  reduction  in  design  space,  engineers 
produce  additional  levels  of  details  of  the  subsystems  to  refine  the  solution,  improve  cost  estimates,  and  reduce 
risk.  Within  a  CAIV  environment,  the  size  of  the  feasible  design  space  must  remain  large  enough  to  encompass 
the  cost  uncertainty.  The  design  space  is  only  reduced  at  a  process  gate  if  the  design  is  sufficiently  detailed  to 
enable  an  accurate  enough  cost  estimate  to  eliminate  regions  of  the  design  space. 

A  marine  engineering  example  of  set -based  design  would  be  the  interaction  of  hull  shape,  propeller  selection,  and 
propulsion  motor  selection.  For  a  range  of  required  displacements  and  deck  area,  the  hull  designer  would  provide 
the  range  of  speed  -  Effective  Horsepower  (EHP)  curves  and  propeller  size  limitations.  For  this  range,  the 
propeller  designer  would  provide  the  marine  engineer  with  achievable  propeller  efficiencies,  associated  shaft 
speed  -  shaft  power  -  ship  speed  curves  along  with  maximum  shaft  speeds  to  preclude  cavitation.  The  propulsion 
engineer  would  look  at  the  range  of  powers  and  shaft  speed  required  and  identify  a  motor  architecture  that  could 
cover  that  region.  The  cost  engineer  would  identify  the  cost  and  cost  uncertainty  that  would  apply  to  the  different 
design  spaces. 

Initially,  intersections  of  the  different  solutions  would  be  identified.  Areas  of  the  design  space  that  are  Pareto- 
dominated,  that  is,  there  are  solutions  that  perform  better  at  lower  cost,  are  eliminated  from  consideration. 
Likewise,  regions  of  the  design  space  for  which  the  estimated  cost  minus  cost  uncertainty  exceed  the  CAIV  target 
are  also  eliminated,  because  there  is  a  small  probability  that  the  CAIV  target  will  be  achieved  in  that  portion  of 
the  design  space.  In  this  manner,  a  design  solution  is  arrived  at  by  eliminating  potential  solutions  rather  than  by 
trying  to  make  a  point  design  “work.” 

Because  a  portion  of  the  cost  uncertainty  will  not  be  realized  until  after  the  design  is  completed,  set -based  design 
is  not  sufficient  by  itself  to  ensure  CAIV.  Other  techniques  that  can  be  implemented  after  design  is  complete, 
such  as  modularity,  can  be  combined  with  set-based  design  to  implement  an  overall  CAIV  acquisition  strategy. 

Reducing  Risk  Contingencies  through  Requirements  Stability 

Requirements  Stability  is  extremely  important  to  CAIV.  Requirements  instability  can  quickly  result  in  unplanned 
design  (and  production)  rework.  This  rework  usually  results  in  additional  costs  that  must  be  offset  by  reductions 
elsewhere.  In  general,  making  design  changes  late  in  the  design  process  or  during  construction  should  be  avoided 
to  the  greatest  extent  practical.  Unless  unavoidable,  requirements  should  not  be  altered  following  the  Preliminary 
Design  Review,  and  configurations  should  not  be  altered  following  the  Critical  Design  Review.  If  a  specific 
requirement  cannot  be  fixed  or  there  is  risk  that  it  may  change  late  in  design  or  construction,  then  the  systems 
architecture  should  be  modular  and  scalable  as  indicated  in  the  previous  section.  This  implies  that  a  program 
should  continuously  evaluate  the  risk  of  a  requirement  changing  over  the  design  and  construction  period,  as  well 
as  during  the  service  life  of  the  system.  The  choice  of  how  to  implement  modularity  must  also  account  for  when 
the  risk  is  likely  to  be  realized  (during  design,  construction,  or  in-service). 

Requirements  Stability  is  not  limited  to  growth  in  requirements.  Late  reductions  in  requirements,  as  in  de-scoping 
efforts  to  reduce  program  costs,  are  also  sources  of  additional  work  that  often  consume  much  of  the  cost  that  is 
intended  to  be  saved. 
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Improving  Design  Flexibility  by  Maintaining  a  Trade-Space 

For  CAIV  to  work,  the  Program  Manager  must  have  flexibility  to  trade  performance  for  cost.  If  the  Program 
Manager  only  budgets  to  achieve  the  threshold  requirements,  then  the  Program  Manager  has  lost  all  flexibility  to 
address  unforeseen  cost  increases.  Early  in  the  design  of  a  system,  the  budget  should  be  set  to  achieve  close  to  the 
objective  values  (about  65  percent  to  85  percent  of  the  threshold  to  objective  range).  The  difference  in  cost  for 
the  capability  between  the  threshold  capability  and  the  budgeted  capability  becomes  a  margin  that  can  be 
consumed  during  the  design  and  construction  of  the  system.  This  can  only  work  if  the  system  design  is  such  that 
the  management  flexibility  is  preserved  (through  modularity  for  example)  to  enable  the  consumption  of  this 
margin. 

Common  CAIV  Challenges 

The  best  way  to  control  costs  is  to  have  sufficient  funds  available  to  get  the  job  done,  and  manage  those  funds 
wisely.  Unfortunately,  for  a  variety  of  reasons  a  Program  Manager  will  discover  that  the  program  does  not  have 
sufficient  funds  to  execute  the  current  program  plan.  When  funding  becomes  “tight,”  usual  responses  include: 

•  Spreading  cuts  along  all  cost  accounts  -  increasing  the  risk  that  the  work  cannot  be  done  correctly  and 
on  schedule  with  the  amount  of  available  funds.  Rework  will  result  in  increased  costs. 

•  Reviewing  every  task  to  cut  any  perceived  margin  -  increasing  the  risk  of  a  cost  overrun.  Tasks  that 
are  perceived  underfunded  are  rarely  plussed  up.  By  cutting  only  the  “overfunded”  tasks  without 
increasing  the  “underfunded”  tasks,  on  average  the  program  will  be  underfunded. 

•  Deferring  work  to  post-delivery  -  often  at  an  increase  in  overall  cost  because  work  is  done  onboard 
where  labor  efficiency  is  much  lower  than  work  performed  in  a  shop  environment  during  the 
construction  process. 

•  Cutting  engineering,  analysis,  documentation,  testing,  and  Government  engineering  oversight  - 
increasing  risk  that  technical  issues  will  be  discovered  late  when  corrective  action  is  very  expensive. 
Keane,  Fireman  and  Billingsley4  provide  evidence  that  “the  most  important  factor  in  ensuring  that 
programs  are  delivered  on  time  and  on  budget  is  increased  funding  in  the  early  stages  of  development.” 
Yet  many  programs  reduce  this  early  stage  work  and  rush  into  production  in  a  generally  unsuccessful 
attempt  to  control  costs. 

•  De-scoping  capability  -  If  not  preplanned,  then  the  cost  to  eliminate  a  capability  from  a  design  will 
require  significant  engineering  (and  potentially  production)  rework.  If  not  de-scoped  early  enough, 
removing  capability  may  increase  costs.  In  any  case,  if  not  preplanned,  the  cost  to  restore  a  de-scoped 
capability  can  be  much  larger  than  the  amount  of  funds  recovered  from  the  de-scoping  effort. 


4  Keane,  R.  G.,  H.  Fireman,  D.  W.  Billingsley,  “Leading  a  Sea  Change  in  Naval  Ship  Design:  Toward  Collaborative  Product 
Development,”  SNAME  Journal  of  Ship  Production,  Volume  23,  Number  2,  May  2007  ,  pp.  53-71. 
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While  each  of  these  responses  can  in  the  short-term  appear  to  cut  costs,  the  resultant  increase  in  risk  over  the  life 
of  the  program  will  likely  result  in  increases  in  cost  and  schedule  slippage  as  individual  risks  are  realized.  As 
shown  in  the  Figure,  a  RAND  study  for  the  U.K.  MoD  found  that  69  percent  of  schedule  slippage  was  due  to 
change  orders,  late  product  definition,  and  lack  of  technical  information  (Arena  et.  al.  2005).  These  results  are 
consistent  with  the  normal  program  management  response  to  predicted  cost  over -runs. 


Other 

Productivity  6% 
8%  \ 


Change  orders/late 
product  definition 
46% 


Figure  UU-1.  Causes  of  Schedule  Slips  Reported  by  Shipbuilders  (percentage)  (Arena  et.al.  2005) 

In  practice,  the  traditional  responses  to  predicted  cost  over -runs  often  increase  program  risk,  but  current  methods 
of  establishing  risk  contingencies  are  not  sensitive  to  individual  risk  items.  The  net  impact  is  that  the  acceptance 
of  risk  results  in  an  increase  of  the  cost  uncertainty,  such  that  the  region  of  uncertainty  includes  the  CAIV  target. 
In  this  way,  the  Program  Manager  can  be  convinced  that  achieving  the  CAIV  target  is  possible,  when  in  reality, 
the  likelihood  of  success  is  even  lower.  The  impact  of  these  typical  responses  is  shown  in  the  Figure.  Because 
the  Committed  cost  is  already  above  the  CAIV  Cost  target  when  the  cost  problem  is  identified,  the  “Corrective 
Action”  merely  appears  to  solve  the  cost  problem  by  increasing  the  size  of  the  Cost  Uncertainty  Region  to 


Figure  UU-2.  CAIV  Attempt  Failure 
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CAIV  is  intended  to  provide  the  Program  Manager  with  the  flexibility  to  trade  performance  for  cost.  For  this  to 
successfully  happen,  the  Program  Manager  must  have  the  ability  to  identify  a  potential  cost  problem  and  take 
corrective  action  before  the  Committed  Cost  curve  crosses  the  CAIV  Cost  target. 

Keeping  committed  costs  low  for  a  prolonged  period  of  time  is  difficult.  Often,  the  point  where  a  design  will  fall 
between  the  threshold  and  objective  values  of  a  requirement  will  be  fixed  early  in  the  design  process  through  the 
selection  of  equipment  and  systems.  Once  equipment  decisions  are  made  and  the  design  evolves  to  incorporate 
the  equipment,  the  flexibility  offered  by  the  threshold  and  objective  values  is  largely  eliminated  -  the  design  point 
becomes  a  de  facto  fixed  requirement.  For  CAIV  to  work,  the  system  architecture  must  be  scalable  such  that  the 
design  point  between  the  threshold  and  objective  can  be  affordably  adjusted  to  respond  to  cost  perturbations  over 
as  much  of  the  life  of  the  acquisition  program  as  possible. 

To  minimize  costs,  some  Program  Managers  (or  customers)  immediately  direct  that  the  program  only  fund  for 
threshold  performance.  The  view  is  “If  the  minimum  wasn’t  good  enough,  it  wouldn’t  be  the  minimum.”  The 
budget  is  then  established  at  the  current  cost  estimate  for  meeting  only  the  threshold  requirements.  As  normal 
variances  in  the  projected  cost  become  apparent  over  time,  the  typical  responses  listed  above  are  implemented. 
The  net  result  is  that  the  program  is  not  executed  in  a  CAIV  environment,  but  rather  on  a  fixed  set  of 
requirements,  with  the  normal  increase  in  costs  due  to  the  typical  response  to  reduce  the  apparent  cost  resulting  in 
actual  cost  increases. 

CAIV  Summarized 

The  Figure  shows  the  essence  of  CAIV.  For  it  to  work,  the  CAIV  Margin  should  remain  positive  over  the  life  of 
the  acquisition.  This  is  difficult  because  all  of  the  elements  of  the  cost  model  (with  the  exception  of  the  CAIV 
Target)  have  associated  uncertainties  and  will  change  values  over  time.  We  would  expect  the  Risk  Contingency 
to  decrease  as  risks  are  either  realized  or  mitigated.  The  Cost  Uncertainty  Region  is  likely  to  become  smaller  as 
uncertainties  are  resolved.  The  Design  Cost  Estimate  will  mature  as  more  is  known  about  the  details  of  the  design 
and  the  cost  of  design,  construction,  and  testing.  Finally,  the  design  flexibility  can  be  expected  to  decline  as 
design  decisions  are  made. 
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Figure  UU-3.  Major  CAIV  Elements 
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For  a  program  to  employ  a  CAIV  acquisition  strategy  effectively,  the  design,  engineering,  and  cost  estimating 
methods  must  be  aligned  to  ensure  that  costs  are  not  committed  so  early  as  to  eliminate  the  flexibility  necessary  to 
react  to  unpredictable  cost  variances.  Techniques  that  assist  the  Program  Manager  and  lead  design  engineer 
include: 


•  Implement  modularity  to  provide  flexibility. 

•  Stabilize  Requirements  -  use  modularity  to  address  requirements  risks. 

•  Provide  a  trade-space  -  don’t  fix  a  design  point  too  early  between  the  threshold  and  objective  values. 

•  Establish  program  budget  wisely  -  include  a  budget  for  risk. 

•  Use  cost  contingencies  wisely  -  be  aware  of  the  effects  of  “Money  allocated  is  Money  Spent”. 

•  Employ  Set-Based  Design  to  improve  design  flexibility. 

•  Eliminate  Sources  of  Cost  Risk  to  reduce  the  funds  allocated  to  risk  contingencies. 

By  employing  these  techniques,  final  design  decisions  can  be  delayed  without  impacting  the  overall  acquisition 
schedule.  By  prolonging  decisions,  flexibility  is  preserved  and  cost  better  controlled. 


UU-10 


S9800-AC-MAN-01 0 


APPENDIX  VV 
COMPLEXITY 

Complexity  deals  with  functions  and  the  way  they  interact  and  interfere  with  each  other  to  prevent  achieving  the 
overall  objectives.  With  this  definition,  complexity  is  a  function  of  process,  not  product.  It  can  also  exist  in 
multiple  dimensions  such  as: 

•  Design  Complexity 

•  Acquisition  Complexity 

•  Production  Complexity 

•  Testing  Complexity 

•  Operations  Complexity 

•  Maintenance  Complexity 

•  Modernization  Complexity 

While  the  dimensions  of  complexity  are  independent  of  each  other,  the  activities  they  act  on  are  inter -related.  For 
example,  the  design  process  has  a  great  influence  on  the  other  dimensions  of  complexity.  Hence  when  we  speak 
of  “Design  for  Production”  we  are  generally  addressing  ways  to  reduce  Production  Complexity.  In  fact  we  may 
elect  to  accept  increased  Design  Complexity  to  reduce  the  other  dimensions  of  complexity  in  search  of  the  lowest 
Total  Ownership  Cost. 

Design  complexity  is  hard  to  define,  but  its  impact  is  well  known.  It  is  claimed  that  complexity  leads  to  fragile 
designs  that  are  very  sensitive  to  small  perturbations.  It  also  complicates  design  management  because  few 
engineers  understand  the  whole  design.  This  can  lead  to  sub-optimal  design  or  different  design  teams  working  to 
cross-purposes.  Complexity  has  not  been  quantified  but  is  seen  as  a  function  of: 

•  “Number  of  ideas  you  must  hold  in  your  head  simultaneously; 

•  Duration  of  each  of  those  ideas;  and 

•  Cross  product  of  those  two  things,  times  the  severity  of  the  interactions  between  them.” 

Nam  Suh,  in  his  book  “Complexity,  Theory  and  Application,”  defines  complexity  as: 

“A  measure  of  the  uncertainty  in  understanding  what  it  is  we  want  to  know  or  in  achieving  a  functional 
requirement  (FR).  Functional  requirements  (FR)  are  defined,  as  in  axiomatic  design,  as  a  minimum  set  of 
independent  requirements  that  completely  characterize  the  functional  needs  of  the  product  in  the  functional 
domain.” 

Based  on  this  definition,  Suh  further  categorizes  complexity  into  Real  Complexity,  Imaginary  Complexity,  and 
Combinatorial  Complexity.  He  also  highlights  the  importance  of  functional  periodicity  for  achieving  stability 
over  long  periods  of  time. 

Real  Complexity 

As  defined  by  Suh,  Real  Complexity  is  time -independent  and  depends  on  the  ability  of  the  design  activities  to 
produce  the  requisite  fidelity.  That  is,  the  probability  that  the  design  activity  results  are  inaccurate.  In  matrix 
based  process  modeling,  this  can  be  addressed  by  having  a  good  understanding  of  the  Controls  and  Mechanisms 
to  ensure  the  output  variable  has  the  requisite  level  of  fidelity.  The  Controls  can  influence  the  number  and 
required  fidelity  of  the  input  variables. 

Imaginary  Complexity 

Imaginary  Complexity  is  a  result  of  not  being  able  to  produce  the  desired  results,  not  because  of  the  inherent 
inaccuracies  of  the  design  activities,  but  because  we  don’t  know  the  optimal  order  of  conducting  the  design 
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activities.  Ideally,  the  systematic  use  of  matrix  during  design  iterations  should  eliminate  much  of  the  Imaginary 
Complexity. 

Combinatorial  Complexity 

Combinatorial  Complexity  results  from  having  many  dependencies  between  the  design  activities,  especially  those 
above  the  diagonal  of  the  matrix.  In  a  design  process  with  combinatorial  complexity,  it  becomes  difficult  to 
determine  how  to  adjust  individual  variables  to  ensure  the  design  converges. 

Functional  Periodicity 

Suh  observes  that  systems  that  are  long-lived  and  stable  tend  to  have  functional  periodicity.  Within  the  design 
processes  described  above,  each  method  has  distinct  iteration  boundaries  or  gates:  each  spiral  of  the  design  spiral, 
each  generation  of  Synthesis  Model  Based  Design  Optimization,  and  each  gate  in  SBD.  These  serve  to  “reset” 
the  instabilities  caused  by  Combinatorial  Complexity. 


Complexity  Metrics 

A  metric  is  a  measure  of  something  of  interest.  To  be  useful,  one  must  be  able  to  calculate  or  measure  the  metric 
and  be  able  to  place  a  value  on  the  metric.  Ideally  an  “improvement”  in  the  metric  should  reliably  result  in  an 
“improvement”  in  the  desired  outcome.  There  are  many  theoretical  metrics  for  complexity,  but  most  fail  the  test 
of  being  readily  calculable. 


One  proposed  complexity  metric  (Figure  VV-1)  is  based  on  a  Space  Complexity  Factor  that  in  turn  is  a  function 
of  the  number  of  systems  and  functional  requirements  that  impact  that  space.  This  complexity  metric  recognized 
that  many  of  the  design  activities  in  later  stages  of  design  are  focused  on  the  arrangement  and  design  of  individual 
spaces  on  a  ship.  The  first  equation  in  Figure  VV-1  shows  the  calculation  of  an  individual  space  complexity 
factor,  and  the  second  equation  is  a  summation  of  the  space  complexity  factors  to  provide  a  ship-level  complexity 
metric. 
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Figure  VV-1.  Space  and  Ship  Complexity  Metrics 
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The  matrix  however,  offers  the  opportunity  to  develop  a  more  generalized  metric  of  Combinatorial  Complexity. 
Combinatorial  Complexity  is  singled  out  because  it  should  have  a  strong  influence  on  the  planning  for  a  design 
process.  As  shown  in  equation  [1],  the  proposed  metric  is  the  sum  of  the  square  of  the  sizes  of  the  clusters. 

n 

Complexity  =  ZC  [‘I 

(=1 

Where:  n  =  Number  of  Clusters  and  C,  =  Size  of  Cluster  “i” 

For  example,  Figure  VV-1  shows  a  matrix  with  complexity  equal  to  1+1+9+1+1=13.  Eliminating  the  cluster  of 
size  3  by  redefining  design  activities  3,  4,  and  5  and  inserting  a  new  integration  activity  6,  the  complexity 
becomes  1+1+1+1+1+1+1+1=8.  In  this  manner,  beneficial  changes  to  the  design  process  can  be  measured  and 
articulated  to  senior  management  as  a  reduction  in  the  complexity  metric. 
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Figure  VV-2.  Less  Complex  Matrix  By  Redefining  Activities 


Complexity  has  a  direct  impact  on  cost.  SEA  05C  has  developed  a  pseudo  complexity  metric  called  “outfit 
density”  which  is  equal  to  (Light  Ship  Displacement  minus  Group  100  weight)  divided  by  ship  volume.  Figure 
VV-3  shows  a  correlation  in  the  first  ship  normalized  engineering  hours  and  outfit  density.  Likewise,  Figure  VV- 
4  shows  a  correlation  in  the  first  ship  production  hours  and  outfit  density. 
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Figure  VV-3.  First  Ship  Engineering  Hours  versus  Outfit  Density 


Figure  VV-4.  First  Ship  Production  Hours  versus  Outfit  Density 
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APPENDIX  WW 

DESIGN  MATURITY  ASSESSMENT 

Near  the  end  of  each  stage  of  design,  the  SDM  shall  prepare  a  Design  Maturity  Assessment  to  demonstrate 
readiness  for  proceeding  into  the  next  stage  of  design  or  production.  Tasks  comprising  the  assessment  include: 

1 .  Identify  the  systems  that  had  modifications  made  to  their  architectures.  Cite  the  number  of  full  design 
iterations  (spirals)  that  have  been  performed.  For  each  design  iteration,  assess  the  overall  magnitude  of  design 
changes  since  the  previous  iteration.  Examples  of  architectures  include: 

•  Hull  -  Hull  form,  stability,  and  arrangement  architectures 

•  Energy  -  Propulsion,  electrical,  and  dynamic  positioning  architectures  and  their  integration 

•  Ship  Information  -  Machinery  control  and  C4I  architectures  and  their  integration 

Architectures  are  considered  “fixed”  when  subsequent  design  development  will  not  require  any  changes  to  these 
architectures. 

2.  To  begin  the  design  convergence  assessment  the  Design  Team  should  develop  a  flow  chart  for  each  system 
similar  to  the  ones  shown  in  Figure  WW-1 .  In  the  example  depicted,  risks  are  assigned  based  on  analytical 
validation.  With  a  “Converged  Design”  there  is  a  high  confidence  that  any  subsequent  changes  to  the  design  will 
not  result  in  significant  changes  in  principal  characteristics  (light  ship  and  full  load  displacement,  volume,  KG, 
etc.)  and  that  future  changes  will  not  deplete  the  remaining  margins.  If  the  design  has  not  converged: 

•  Provide  details  of  exactly  which  portions  of  the  design  have  not  converged 

•  Identify  specific  actions  required  to  bring  those  items  into  convergence 

•  Delineate  the  technical  risks  associated  with  each  non-convergence  item 
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Figure  WW-1.  System  Design  Convergence  Flow  Chart 
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3.  Establish  that  design  artifacts  reflect  fixed  architectures  and  are  consistent  with  each  other.  State  which  design 

iteration  number  and/or  design  baseline  date  that  each  design  artifact  is  based  on).  Examples  of  design  artifacts  to 

assess  include: 

•  General  Arrangement  Drawings 

•  System  Design  1  Weight  Estimate 

•  Intact  &  Damaged  Stability  Report 

•  Speed  and  Power  Analysis 

•  Dynamic  Positioning  System  Report 

•  Ship  Structural  Design  Analysis 

•  Propulsion  System  Report 

•  Machinery  Arrangement  Drawings 

•  Machinery  Centralized  Control  System  Report 

•  Master  Equipment  List 

•  Electrical  Plant  Load  Analysis 

•  Electrical  System  One -Line  Diagram 

•  Command,  Control,  Communications,  Computers  and  Intelligence  (C4I)  Report 

•  Interior  Communications  System  Design  Report 

•  Rapid  Ballast  System  Diagram 

•  Firemain  System  Design  Report  &  Diagram 

•  Fixed  Firefighting  System  Design  Report 

•  Aqueous  Film  Forming  Foam  (AFFF)  System  Design 

•  Report  and  Diagram 

•  Aviation  Support  Systems  Design  Report 

•  Surface  Connector  Interface,  Stowage,  &  Handling  Report 

•  Vehicle  Maneuvering  and  Stowage  Study  Report 

•  Vehicle  Transfer  System  (VTS)  Design  Report 

4.  Identify  novel  features  of  the  design. 

5.  Assess  the  risk  that  significant  design  changes  will  occur  in  subsequent  stages  of  design.  Use  the  Program’s 
Risk  Management  System  to  report  risks  and  develop  risk  mitigation  plans. 

6.  Identify  all  areas  of  non-compliance  with  the  Ship  Specification.  For  any  areas  of  non-compliance,  list  those 
areas  with  a  supporting  explanation,  provide  the  remediation  plan  and  identify  which  (if  any)  of  those  areas  will 
have  an  effect  on  design  convergence. 

7.  List  the  analyses  done  in  support  of  the  converged  design  and  analyses  remaining  for  future  stages  of  design. 

8.  Identify  the  margins  allocated  for  the  current  stage  of  design  and  how  much  of  each  margin  was  consumed. 
Provide  supporting  evidence  to  confirm  that  adequate  margins  exist  for  the  remaining  design  phases  and 
production. 

9.  Assess  the  overall  risk  that  a  ship  constructed  based  on  the  information  contained  in  the  design  artifacts  will 
ultimately  be  successfully  classified  by  ABS  for  applicable  T-ships  and  recommended  for  acceptance  by 
INSURV.  Use  the  program’s  Risk  Management  System. 
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APPENDIX  XX 
ACRONYMS 


AAP 

Abbreviated  Acquisition  Program 

ABS 

American  Bureau  of  Shipping 

ACAT 

Acquisition  Category 

ACO 

Administrative  Contracting  Officer 

ACP 

Alternative  Compliance  Program 

ACSAE 

Air  Capable  Ship  Aeronautical  Equipment 

ADM 

Acquisition  Decision  Memorandum 

AEA 

Annual  Execution  Agreement 

AEM/S 

Advanced  Enclosed  Mast/Sensor  System 

AER 

Alteration  Equivalent  to  Repair 

AFFF 

Aqueous  Film  Forming  Foam 

AFOM 

Alteration  Figure  of  Merit 

AIT 

Alteration  Installation  Team 

AoA 

Analysis  of  Alternatives 

ALRE 

Aircraft  Launch  and  Recovery  Equipment 

ANSI 

American  National  Standards  Institute 

AP 

Acquisition  Plan 

APB 

Acquisition  Program  Baseline 

AS 

Acquisition  Strategy 

ASAP 

Advanced  Survivability  Assessment  Program 

ASSET 

Advanced  Surface  Ship  Evaluation  Tool 

ASN(RD&A) 

Assistant  Secretary  of  the  Navy  (Research,  Development,  and  Acquisition) 

ASR 

Alternative  Systems  Review 

ASTM 

American  Society  of  Testing  Materials 

ASW 

Anti-Submarine  Warfare 

AV 

All- View 

BAWP 

Baseline  Authorized  Work  Package 

BUMED 

Bureau  of  Medicine 

C4I 

Command,  Control,  Communications,  Computers  and  Intelligence 

C4ISR 

Command,  Control,  Communications,  Computers,  Intelligence, 
Surveillance  and  Reconnaissance 

CAD 

Computer-Aided  Design 
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CAFSU 

Computer-Assisted  Design 

Carrier  and  Field  Service  Unit 

CAIG 

Cost  Analysis  Improvement  Group 

CAIV 

Cost  as  an  Independent  Variable 

CALS 

Computer-Aided  Acquisition  and  Logistics  Support 

CAM 

Computer-Aided  Manufacturing 

CAPS 

Carrier  Availability  Planning  System 

CARD 

Cost  Analysis  Requirements  Description 

CASREP 

Casualty  Report 

CB 

Center  of  Buoyancy 

CBA 

Capabilities  Based  Assessment 

CBR 

Cost  Benefits  Analysis 

Chemical,  Biological,  and  Radiological 

CCB 

Change  Control  Board 

CCBL 

Configuration  Control  Board 

Configuration  Control  Baseline 

CD 

Contract  Design 

CDD 

Capability  Development  Document 

CDM 

Competency  Domain  Manager 

CDMS 

Corporate  Document  Management  System 

CDR 

Critical  Design  Review 

CER 

Cost  Estimating  Relationships 

CET 

Cost  Engineering  Team 

CFE 

Contractor  Furnished  Equipment 

CFM 

Contractor  Furnished  Material 

CFR 

Code  of  Federal  Regulation 

CFT-4 

Cross  Functional  Team  Four 

CHENG 

Chief  Engineer 

Cl 

Configuration  Item 

CISD 

Center  for  Innovation  in  Ship  Design 

CJCSI 

Chairman,  Joint  Chiefs  of  Staff  Instruction 

CLIN 

Contract  Line  Item 

CLO 

Counter  Low  Observable 

CM 

Configuration  Management 
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CMC 

Change  Manager 

Commandant  of  the  Marine  Corps 

CNAF 

Commander  Naval  Air  Forces 

CNSF 

Commander  Naval  Surface  Forces 

CNO 

Chief  of  Naval  Operations 

COI 

Certificate  of  Inspection 

COMFLTFORCOMINST 

Commander,  Fleet  Forces  Command  Instruction 

COMNAVAIR 

Commander,  Naval  Air  Systems  Command 

COMNAVSEACOM 

Commander,  Naval  Sea  Systems  Command 

COMOPTEVFOR 

Commander,  Operational  Test  and  Evaluation  Force 

CONOPS 

Concept  of  Operations 

COSAL 

Coordinated  Shipboard  Allowance  Fist 

CPA 

Carrier  Planning  Activity 

CPAT 

Corrosion  Prevention  Advisory  Team 

CPCP 

Corrosion  Prevention  and  Control  Plan 

CPD 

Capability  Production  Document 

CPI 

Critical  Program  Information 

CPSD 

Cost  Performance  Schedule  Description 

CRD 

Certification  Requirements  Document 

CRL 

Cost  Readiness  Fevel 

CSA 

Customer  Service  Agreement 

CSB 

Configuration  Steering  Board 

CSE 

Class  Standard  Equipment 

CSEL 

Chief  Systems  Engineer 

Combat  Systems  Equipment  Fist 

CSI 

Critical  Safety  Item 

CSMP 

Current  Ship’s  Maintenance  Project 

CTT 

Combined  Test  Team 

DA 

Design  Agent 

DAB 

Defense  Acquisition  Board 

DARPA 

Defense  Advanced  Research  Projects  Agency 

DASN 

Deputy  Assistant  Secretary  of  the  Navy 

DC 

Damage  Control 

DCA 

Defense  Contracting  Agency 
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DD&C 

Detail  Design  and  Construction 

DDR 

Design  Decision  Review 

DFARS 

Defense  Federal  Acquisition  Regulation  Supplement 

DFS 

Departure  from  Specification 

Deviation  from  Specification 

DI 

Data  Item 

DIM 

Design  Integration  Manager 

DISA 

Defense  Information  Systems  Agency 

DMA 

Design  Maturity  Assessment 

DoD 

Department  of  Defense 

DoDAF 

DoD  Architecture  Framework 

DoN 

Department  of  the  Navy 

DoN  CIO 

Department  of  Navy  Chief  Information  Officer 

DOSE 

Decision  Oriented  Systems  Engineering 

DOT&E 

Director,  Operational  Test  and  Evaluation 

DOTMLPF 

Doctrine,  Organization,  Training,  Materiel,  Leadership,  Personnel,  and 
Facilities 

DRL 

Data  Requirements  List 

DRM 

Design  Reference  Mission 

DRPM 

Direct  Reporting  Program  Manager 

DS 

Down  Select 

DSEM 

Deputy  Systems  Engineering  Manager 

DSM 

Design  Structure  Matrix 

DUSD 

Deputy  Under  Secretary  of  Defense 

DT&E 

Developmental  Test  and  Evaluation 

DTIC 

Defense  Technical  Information  Center 

DWO 

Deputy  Warranting  Officer 

EA 

Engineering  Agent 

ECD 

Estimated  Completion  Date 

ECM 

Engineering  Configuration  Manager 

ECP 

Engineering  Change  Proposal 

EFR 

Engineering  Field  Representatives 

EHP 

Effective  Horsepower 

EIA 

Electronic  Industries  Alliance 

EMC 

Electromagnetic  Compatibility 
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EMD 

Engineering  Manufacturing  and  Development 

EMI 

Electromagnetic  Interference 

EMP 

Electromagnetic  Pulse 

EO 

Executive  Order 

EP 

Entitled  Process 

ERP 

Enterprise  Resources  Planning 

ESOH 

Environmental,  Safety  and  Occupational  Health 

ESWBS 

Expanded  Ship  Work  Breakdown  Structure 

EVMS 

Earned  Value  Management  System 

FAA 

Functional  Area  Analysis 

FAR 

Federal  Acquisition  Regulation 

FAS 

Fueling  at  Sea 

FCA 

Functional  Configuration  Audit 

FCB 

Functional  Coordination  Board 

FEA 

Finite-Element  Analysis 

FLO  FLO 

Float  On  Float  Off 

FMA 

Fleet  Maintenance  Activity 

FMP 

Fleet  Modernization  Program 

FMR 

Field  Modification  Request 

FNA 

Functional  Needs  Analysis 

FOC 

Full  Operational  Capability 

FOUO 

For  Official  Use  Only 

FRC 

Federal  Record  Center 

FRP  DR 

Full  Rate  Production  Decision  Review 

FS 

Feasibility  Study 

FSA 

Functional  Solution  Analysis 

FSC 

Full  Service  Contractor 

FTE 

Full-Time  Equivalent 

FY 

Fiscal  Year 

GFE 

Government  Furnished  Equipment 

GFI 

Government  Furnished  Information 

GFM 

Government  Furnished  Material 

GIDEP 

Government-Industry  Data  Exchange  Program 

GSO 

General  Specifications  for  Overhaul 
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HCDD 

Human  Capital  Digital  Dashboard 

HERF 

Hazards  of  Electromagnetic  Radiation  for  Fuel 

HERO 

Hazards  of  Electromagnetic  Radiation  for  Ordnance 

HERP 

Hazards  of  Electromagnetic  Radiation  to  Personnel 

HF 

High  Frequency 

HFE 

Human  Factors  Engineering 

HM&E 

Hull,  Mechanical  and  Electrical 

HQMC 

Headquarters  Marine  Corps 

HSC 

High  Speed  Craft 

HSI 

Human  Systems  Integration 

HSNC 

High  Speed  Naval  Craft 

HVAC 

Heating,  Ventilation,  and  Air  Conditioning 

IA 

Information  Assurance 

IACS 

International  Association  of  Classification  Societies 

IBR 

Integrated  Baseline  Review 

ICD 

Initial  Capabilities  Document 

ICMP 

Integrated  Class  Maintenance  Plan 

I/COSAL 

Integrated  Coordinated  Shipboard  Allowance  List 

IDE 

Integrated  Digital  Environment 

IDEA 

Integrated  Design  Engineering  Environment 

IDEE 

Integration  Definition 

IDPME 

Integrated  Data  and  Product  Model  Environment 

IEEE 

Institute  of  Electrical  &  Electronics  Engineers 

IFF 

Identification  Friend  or  Foe 

ILA 

Independent  Logistics  Assessment 

ILS 

Integrated  Logistics  Support 

IMO 

International  Maritime  Organization 

IMP 

Integrated  Management  Plan 

INFOSEC 

Information  Systems  Security 

INSURV 

(Board  of)  Inspection  and  Survey 

IOC 

Initial  Operational  Capability 

IOT&E 

Initial  Operational  Test  and  Evaluation 

IPDE 

Integrated  Product  Development  Environment 

Integrated  Product  Data  Environment 
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IPPD 

Integrated  Product  and  Process  Development 

IPT 

Integrated  Product  Team 

IPT4ACM 

Integrated  Project  Teams  for  Aircraft  Carrier  Maintenance 

IR 

Infra  Red 

IRR 

Integrated  Readiness  Review 

ISE 

In  Service  Engineering 

ISEA 

In  Service  Engineering  Agents 

ISO 

International  Organization  of  Standardization 

ITAR 

International  Traffic  in  Arms  Regulation 

ITD 

Integrated  Topside  Design 

ITR 

Initial  Technical  Review 

IWS 

Integrated  Warfare  Systems 

IWSE 

Integrated  Warfare  Systems  Engineering 

JCB 

Joint  Capabilities  Board 

JCF 

Justification  Cost  Form 

JCIDS 

Joint  Capabilities  Integration  and  Development  System 

JFCOM 

Joint  Forces  Command 

JFMM 

Joint  Fleet  Maintenance  Manual 

JIT 

Just-In-Time 

JITC 

Joint  Interoperability  Test  Command 

JROC 

Joint  Requirements  Oversight  Council 

KG 

Ship’s  Center  of  Gravity  Above  Keel 

KPP 

Key  Performance  Parameter 

KSA 

Key  System  Attribute 

LAR 

Liaison  Action  Record 

LCM 

Life  Cycle  Manager 

LEAPS 

Leading  Edge  Architecture  for  Prototyping  Systems 

LFT&E 

Live  Fire  Test  and  Evaluation 

LO 

Low  Observable 

LOE 

Level  of  Effort 

LSE 

Lead  Systems  Engineer 

MACHALTS 

Machinery  Alterations 

MARPOL 

International  Convention  for  the  Prevention  of  Pollution  from  Ships 

MAS 

Modular  Adaptable  Ship 
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MDA 

Milestone  Decision  Authority 

MDD 

Materiel  Development  Decision 

MEL 

Major  (or)  Master  Equipment  List 

MI 

Material  Inspections 

MILSPEC 

Military  Specification 

MIL-STD 

Military  Standard 

MIRWS 

Master  Integrated  Resource  and  Work  Schedule 

MIT 

Massachusetts  Institute  of  Technology 

MOA 

Memorandum  of  Agreement 

MOS 

Management  Operating  System 

MOSA 

Modular  Open  Systems  Architecture 

MOU 

Memorandum  of  Understanding 

MPF(F) 

Maritime  Prepositioning  Force  (Future) 

MRP 

Multiservice  Route  Processor 

MS 

Milestone 

MSC 

Military  Sealift  Command 

NAB 

NAVSEA  Adjudication  Board 

NACT 

Naval  Advanced  Concepts  and  Technologies 

NATO 

North  Atlantic  Treaty  Organization 

NAVAIR 

Naval  Air  Systems  Command 

NAVAIRLAKEHURSTACDIV 

Naval  Air  Warfare  Center  Aircraft  Division,  Lakehurst,  NJ 

NAVCOMPT 

Navy  Comptroller 

NAVMED 

Naval  Medical  Command 

NAVOSH 

Navy  Occupational  Safety  and  Health 

NAVSEA 

Naval  Sea  Systems  Command 

NAVSEAINST 

NAVSEA  Instruction 

NAVSO 

Navy  Staff  Office 

NAVSUP 

Naval  Supply  Systems  Command 

NCAD 

Naval  Cost  Analysis  Division 

NCETL 

Naval  Concept  Essential  Task  List 

NDE 

Navy  Data  Environment 

NEEC 

Naval  Engineering  Education  Center 

NEMP 

Nuclear  Electromagnetic  Pulse 

NEPA 

National  Environmental  Policy  Act 
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NETC 

Naval  Education  and  Training  Command 

NFAF 

Naval  Fleet  Auxiliary  Force 

NGNN 

Northrop  Grumman  Newport  News 

NIPO 

Navy  International  Programs  Office 

NISO 

National  Information  Standards  Organization 

NKO 

Navy  Knowledge  Online 

NFFS 

Navy  Lessons  Learned  System 

NMCI 

Navy  Marine  Coips  Internet 

NMP 

Navy  Modernization  Process 

NN 

Newport  News 

NNSY 

Norfolk  Naval  Shipyard 

NOFORN 

Not  Releasable  to  Foreign  Nationals/Governments/Non-US  Citizens 

NPS 

Naval  Postgraduate  School 

NRE 

Non-recurring  Engineering 

NRMD 

Nuclear  Regional  Maintenance  Department 

NSA 

Naval  Supervising  Authority 

NSRO 

NAVSEA  Shipyard  Representative’s  Office 

NSS 

National  Security  Systems 

NSTISSP 

National  Security  Telecommunications  and  Information  Systems  Security 
Policy 

NSTM 

Naval  Ships  Technical  Manual 

NSWC 

Naval  Surface  Warfare  Center 

NUWC 

Naval  Undersea  Warfare  Center 

NVR 

(ABS)  Naval  Vessel  Rules 

NWCF 

Navy  Working  Capital  Fund 

O&MN 

Operations  and  Maintenance,  Navy 

OCI 

Organizational  Conflict  of  Interest 

OGA 

Other  Government  Activity 

OIPT 

Overarching  Integrated  Product  Team 

OMB 

Office  of  Management  and  Budget 

ONR 

Office  of  Naval  Research 

OPEVAF 

Operational  Evaluation 

OPNAV 

Office  of  the  Chief  of  Naval  Operations 

OPNAVINST 

OPNAV  Instruction 

OPSEC 

Operations  Security  (Manual) 
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OR 

Owner’s  Representative 

ORD 

Operational  Requirements  Document 

ORDALT 

Ordnance  Alteration 

OSJTF 

Open  Systems  Joint  Task  Force 

OSR 

On-Site  Representative 

OTRR 

Operational  Test  Readiness  Review 

OV 

Operational  View 

OWLD 

Obligation  Work  Limiting  Date 

PARM 

Participating  Acquisition  Resource  Manager 

PART 

Program  Assessment  and  Rating  Tool 

PBL 

Performance  Based  Logistics 

PCO 

Procuring  Contracting  Officer 

PD 

Preliminary  Design 

PDM 

Product  Data  Model 

Program  Decision  Meeting 

PDR 

Preliminary  Design  Review 

PDS 

Project  Data  Sheet 

PEO 

Program  Executive  Officer 

Program  Executive  Office 

PLCCE 

Program  Life  Cycle  Cost  Estimate 

PM 

Program  Manager 

PME 

Project  Marine  Engineer 

PMR 

Program  Manager  Representative 

PMT 

Program  Management  Team 

PNA 

Project  Naval  Architect 

POA&M 

Plan  of  Action  and  Milestones 

POC 

Point  of  Contact 

POM 

Program  Objectives  Memorandum 

PPBES 

Program  Planning  Budgeting  and  Execution  System 

PPD 

Project  Peculiar  Document 

PPEA 

Propulsion  Plant  Engineering  Activity 

PPP 

Program  Protection  Plan 

PRR 

Production  Readiness  Review 

PSA 

Post  Shakedown  Availability 
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PSI 

Pounds  Per  Square  Inch 

PSNSY 

Puget  Sound  Naval  Shipyard 

PY 

Planning  Yard 

QA 

Quality  Assurance 

QCD 

Quality,  Cost,  and  Deliver 

R&D 

Research  and  Development 

R&SE 

Research  and  Systems  Engineering 

RADHAZ 

Radiation  Hazard 

RAM 

Reliability,  Availability,  and  Maintainability 

RAS 

Replenishment  at  Sea 

RAST 

Recovery,  Assist,  Secure  and  Traverse 

RCIA 

Request  for  Clarification,  Information  and  Assistance 

RCOH 

Refueling  Complex  Overhaul 

RCS 

Radar  Cross  Section 

RDT&E 

Research,  Development,  Test  and  Evaluation 

RED 

Request  for  Deviation 

RFP 

Request  for  Proposal 

RFW 

Request  for  Waiver 

RIYD 

Required  In  Yard  Date 

RMC 

Regional  Maintenance  Center 

ROM 

Rough  Order  of  Magnitude 

RPPY 

Reactor  Plant  Planning  Yard 

RS&E 

Research  and  Systems  Engineering 

RTM 

Requirements  Traceability  Manager 

S&T 

Science  and  Technology 

SAMP 

Single  Acquisition  Management  Plan 

SAR 

Ship  Alteration  (SHIP ALT)  Record 

SATCOM 

Satellite  Communications 

SBD 

Set  Based  Design 

SBIR 

Small  Business  Innovative  Research 

SCD 

Ship  Change  Document 

SCF 

Space  Complexity  Factor 

SCM 

Ship  Concepts  Manager 

Ship  Certification  Matrix 
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SCN 

Ship  Class  Manager 

Ship  Complexity  Metric 

Ship  Construction  Navy 

SDCN 

Ship  Design  and  Certification  Network 

SDM 

Ship  Design  Manager 

SDR 

Ship  Design  Review 

SDS 

System  Design  Specification 

SDT 

Ship  Design  Team 

SECNAV 

Secretary  of  the  Navy 

SECNAVINST 

Secretary  of  the  Navy  Instruction 

SEM 

System  Engineering  Manager 

SEP 

System  Engineering  Plan 

SETR 

Systems  Engineering  Technical  Review 

SF 

Standard  Form 

SFAC 

Statements  of  Financial  Accounting  Concepts 

SFR 

System  Functional  Review 

SHCP 

Ship  Hullform  Characteristics  Program 

SHIP  ALT 

Ship  Alteration 

SHIPMAIN 

Ship  Maintenance 

SIG 

Ship  Integration  Group 

SIM 

Systems  Integration  Manager 

SIPM 

Systems  Integration  PM 

SLEP 

Service  Life  Extension  Program 

SME 

Subject  Matter  Expert 

SOLAS 

Safety  of  Life  at  Sea 

SOM 

SUPSHIP  Operations  Manual 

SORM 

Ship’s  Organizational  and  Regulations  Manual 

SoS 

System-of-Systems 

SOW 

Statement  of  Work 

SPAR 

Steam  Plant  Action  Request 

SPAWAR 

Space  and  Warfare  Systems  Command 

SPD 

Ship  Project  Directive 

SPLI 

Steam  Plant  Liaison  Inquiry 

SPM 

Ship  Program  Manager 

XX-12 


S9800-AC-MAN-01 0 


Smart  Product  Model 

SPP 

Sponsor’s  Program  Proposal 

SPPC 

Ship  Production  Progress  Conferences 

SRG 

Survivability  Review  Group 

SRR 

System  Requirements  Review 

SS 

Source  Selection 

SSAC 

Source  Selection  Advisory  Council 

SSB 

Stakeholders  Steering  Board 

SSC 

Ship-to-Shore  Connector 

SSLCM 

Surface  Ship  Life  Cycle  Maintenance  Activity 

SSP 

Source  Selection  Plan 

STAR 

System  Threat  Assessment  Report 

STILO 

Scientific  and  Technical  Intelligence  Liaison  Officer 

STM 

Specification  Task  Manager 

SUPSHIP 

Supervisor  of  Shipbuilding 

SURFOR 

Surface  Forces 

SV 

System  View 

SVM 

Ship  Vulnerability  Model 

SWARF 

Senior  Warfighter  Forum 

SWATH 

Small- Waterplane  Area  Twin-Hull 

SWBS 

Ship  Work  Breakdown  Structure 

SYSCOM 

Systems  Command 

T&E 

Test  and  Evaluation 

TACA 

Technical  Authority  Capability  Assessment 

TACAN 

Tactical  Air  Navigation 

TAT 

Technical  Assessment  Team 

TD 

Technical  Director 

TDM 

Technical  Domain  Manager 

TEMP 

Test  and  Evaluation  Master  Plan 

TEMPEST 

Telecommunications  Electronics  Material  Protected  from  Emanating 
Spurious  Transmissions 

TES 

Test  and  Evaluation  Strategy 

TFA 

Technical  Feasibility  Assessment 

TIM 

Topside  Integration  Manager 

TL 

Task  Leader 
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TMA 

Top  Management  Attention 

TMI 

Top  Management  Issues 

TOC 

Total  Ownership  Cost 

TPM 

Technical  Performance  Measures 

TRANSCOM 

Transportation  Command  (U.S.) 

TRB 

Technical  Review  Board 

TREE 

Transient  Radiation  effects  in  Electronics 

TRL 

Technology  Readiness  Level 

TRR 

Test  Readiness  Review 

TSSE 

Total  Ship  System  Engineering 

TSTP/SP 

Total  Ship  Test  Program  for  Ship  Production 

TTSARB 

Technology  Transfer  and  Security  Assistance  Review  Board 

TV 

Technical  Standards  View 

TWH 

Technical  Warrant  Holder 

TYCOM 

Type  Commander 

UMI 

Underway  Material  Inspection 

UNREP 

Underway  Replenishment 

UNTL 

Universal  Navy  Task  List 

use 

United  States  Code 

USCG 

United  States  Coast  Guard 

USD  (AT&L) 

Under  Secretary  of  Defense  for  Acquisition,  Technology  and  Logistics 

USNA 

U.S.  Naval  Academy 

VA 

Value  Analysis 

VAMOSC 

Visibility  and  Management  of  Operation  and  Support  Cost 

VE 

Value  Engineering 

VERTREP 

Vertical  Replenishment 

VLA 

Visual  Landing  Aid 

VRT 

Voyage  Repair  Team 

VT 

Virginia  Tech  (Virginia  Polytechnic  Institute  and  State  University) 

VTL 

Virtual  Technical  Library 

VTS 

Vehicle  Transfer  System 

VV&A 

Verification,  Validation,  and  Accreditation 

WBS 

Work  Breakdown  Structure 

WG 

Working  Group 
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WIPT 

WSESRB 

WTA 


Working-level  Integrated  Product  Team 
Weapons  Systems  Explosive  Safety  Review  Board 
Work  Task  Assignment 
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